DStarDB

Redis is famously fast at the head of the latency distribution and famously single-threaded at the tail. Every command — SET, LPUSH, ZADD — serialises through one event loop, and once the queue depth crosses the CPU's ability to drain it, the p99 climbs even though the median is still under a millisecond.

On modern hardware that single thread is the only hot core. The other 7, 15, 63 cores sit at 5 % utilisation. DStarDB starts from the observation that a single-process, single-thread design wastes 90 %+ of the machine you've already paid for.

The network thread runs select() over the listening socket plus every client socket. Its only job is to read bytes off the wire into a per-client buffer and announce that a command is ready. No parsing, no execution, no hash-map lookups happen on this thread.

Every ready command is enqueued onto a GlobalThreadPool of N worker threads. Workers grab tasks from a std::queue<std::function<void()>> guarded by a single std::mutex + std::condition_variable. Once a worker has a command it parses, executes, and writes the response back to the client socket itself — no second hop through the event loop.

Inside a worker the buffered text turns into a concrete ICommand instance via a CommandFactory. There are 40-odd concrete classes — SETCommand, GETCommand, LPUSHCommand, HGETALLCommand, ZRANGECommand, XADDCommand — each in its own header under include/Database/Commands/ConcreteCommands/.

Adding a new command is one new header that derives from ICommand plus one registration line. The processor, the wire protocol, the persistence layer stay closed for modification.

A key in DStarDB doesn't point to a string — it points to a Record, and the record points to an IValue interface. Six concrete implementations sit behind that interface: strings, lists, hashes, sorted sets, streams (with consumer groups), and HyperLogLog.

Polymorphism here isn't theoretical — it shows up at the type system. A LPUSH on a key whose value is a string fails the dynamic-cast and returns a WRONGTYPE error; a brand-new key constructs a ListValue via the factory and pushes into it. The browser REPL below preserves the same semantics.

Time-to-live could have been a field on Record checked everywhere keys are touched. Instead it's a TTLDatabaseDecorator that wraps the database; the inner Database doesn't know TTL exists. Reaping happens on read (lazy expiry) and via a background sweep that runs on the global pool.

Durability follows the same pattern. SnapshotPersistence and AOFPersistence both implement IDatabaseObserver and register with the database. Every mutation triggers onDatabaseModified(operation, recordId). The AOF writer holds a single mutex and appends to disk; the snapshot writer fires on an interval, scoops the in-memory state, and serialises through the same IValue::serialize() interface used on the wire.

Running the in-browser BENCH ports on an M1 reports ~1.5 M ops/sec for SET. The reference number for redis-benchmark single-thread is ~145 k ops/sec. The 10× isn't from a magic data structure — it's from giving the work to all the cores instead of one.

Latency tells the same story differently: p50 / p90 / p99 land at 0 µs (below our timer resolution), p999 around 100 µs. Tail latency stays bounded because no single worker thread serialises behind any other.

Everything above runs in your browser tab via a JS port of the same command surface. Workers, the worker pool, IValue dispatch, TTL decorator, even BENCH — same shapes. Type SET foo bar, LPUSH stack 1 2 3, BENCH SET 100000 and watch the latencies.