Arqly
Sign in
#06Build a distributed SQL engine (CockroachDB-style)
stub
SQL on top of a sea of Raft groups. Build a serializable, horizontally-scaled SQL database where every range is its own Raft group, transactions stitch commits across ranges, and the SQL layer is just an interpreter over a distributed KV store. Internalize why a single transaction can touch dozens of consensus groups and still be correct.

Build a distributed SQL engine (CockroachDB-style). SQL on top of a sea of Raft groups. Build a serializable, horizontally-scaled SQL database where every range is its own Raft group, transactions stitch commits across ranges, and the SQL layer is just an interpreter over a distributed KV store. Internalize why a single transaction can touch dozens of consensus groups and still be correct.

This problem is a stub. Suggested approaches haven't been authored yet — ask the staff engineer in the right panel for any stage and they'll generate one tuned to your draft.
Reading: Taft et al. — CockroachDB: The Resilient Geo-Distributed SQL Database (SIGMOD 2020) · CockroachDB design document (cockroachdb/cockroach/docs/design.md) · CockroachDB blog — Living Without Atomic Clocks · CockroachDB blog — Parallel Commits: An Atomic Commit Protocol for Globally Distributed Transactions · Bernstein, Hadzilacos, Goodman — Concurrency Control and Recovery in Database Systems (Ch. 4–7) · TiDB / TiKV docs — comparable architecture, sometimes clearer prose
range-based sharding (KV ranges, ~64 MB default)
one Raft group per range (thousands of groups per node)
MVCC + hybrid logical clocks (HLC) — no atomic clocks required
distributed transactions: transaction record + intents + parallel commit
serializable isolation under SSI (no read locks)
SQL → KV translation (SQL layer is stateless over the KV layer)
range splits, merges, and rebalancing under load
leaseholder vs Raft leader (read fast path)
follower reads / closed timestamps
schema changes as background descriptor migrations
No scenes authored for this problem yet.