Cardinal
A sharded time-series database where the interesting product work happens below the interface: bytes, routing, recovery, and trust.
A portfolio full of interfaces can prove taste. Cardinal proves I can reason about the machinery underneath the interface.
Cardinal is built as two systems on purpose. The C++ engine owns the bytes-and-cache-lines work: Gorilla-style compression, a CRC-checked write-ahead log, in-memory head blocks, immutable chunks, range queries, and aggregation. The Go control plane owns the work that wants concurrency and operational clarity: HTTP ingestion and query APIs, a binary-protocol engine client, consistent-hash routing, backpressure, cardinality guards, and Prometheus metrics.
The split is the point. Keeping the engine as its own daemon creates a harder boundary than a library call, but it buys crash isolation, independent profiling, and a clean seam for transport changes. Local ingest can use a shared-memory single-producer/single-consumer ring. Remote ingest and queries stay on the framed Unix-socket protocol. Each path is explicit about what it optimizes for.
The cluster story is small but real: write quorum, read consistency, replica placement by consistent hash, and read-repair behavior are all part of the public surface. Cardinal is not pretending to be a production database. It is doing the honest portfolio version of one: a complete vertical slice with enough architecture to discuss correctness, durability, and tradeoffs without hand-waving.
“The interesting part is not that there is a database. It is that the API, router, WAL, compression layer, and tests all agree about where trust begins.”
The language boundary is load-bearing
C++ owns compression, WAL replay, chunk layout, and shared-memory ingest; Go owns the HTTP API, routing, admission control, metrics, and cluster coordination.
Durability is demonstrated, not implied
Writes pass through a CRC-checked WAL, recovery stops cleanly on torn records, and the case study can explain what the system acknowledges and why.
Tests caught real systems bugs
Property tests, sanitizer runs, race checks, fuzz-style garbage input, and end-to-end roundtrips are part of the story, including bugs found in encoding, allocation bounds, and drop accounting.