Nubmq: A high performant key-value store engine built from first principles

What first principles were used to build this?

First principle? Don't respect traditions—burn them.

No threads waiting on locks, no hard pauses for resizes, no conventional polling mechanisms. Instead, nubmq's entire architecture revolves around one relentless obsession: never let a client wait. Everything else—adaptive sharding, real-time migrations, soft expiry handling—is just engineering fallout from aggressively challenging every assumption Redis and Memcached made decades ago.

Would love to see which of these breaks with convention you're most curious (or skeptical) about!

I am interested in the assumptions or new paradigms. How to distinguish “from first principles” from “intuitively from scratch”?

Most 'built from scratch' projects still borrow heavily from established thinking—just reimplementing known patterns in different languages or flavors. But first principles means ripping out the assumptions entirely, starting with raw, fundamental constraints: CPU cycles, memory latency, concurrent I/O contention. nubmq doesn't assume that traditional sharding, resizing, or even Redis's single-threaded event loop is optimal just because they're popular. Instead, it assumes almost nothing: keys have to move fast, scaling must be invisible, and downtime is unacceptable. In other words: Don't just tweak existing approaches, burn them to the ground and rebuild from physics upwards. If your 'from scratch' doesn't actively challenge foundational assumptions, it's just another coat of paint—not a true redesign

To put it bluntly—most engineers today confuse complexity with sophistication. They're stacking libraries and frameworks without questioning if that complexity is needed. nubmq rejects that entirely. It's built on the rawest form of engineering, directly controlling memory, buffers, and goroutine allocation, skipping every third-party crutch that developers usually depend on. It might look radical, even uncomfortable, but that's exactly why it's performant. So, my question back is—are modern developers too afraid to actually build systems this way? Or have we simply gotten complacent with our convenient abstractions?

I vote for the hypothesis of them being complacent and wanting to score quick and easy wins.

In terms of therapeutic approaches I can't blame them but you are right that a lot of the current technology is too old and doesn't even make good use of all the good innovation that has been happening for now decades.

Case in point: so many programs are still single-threaded.