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.

stub

SavedSaved on this device

The problem

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.

What you will cover

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

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

No scenes authored for this problem yet.

About Build a distributed SQL engine (CockroachDB-style)

Difficulty: advanced
Time: about 100 minutes
Stages: 9
Topic: Transactions, Concurrency & Money

How this problem is worked

Nine stages, from what the thing is for to how it compares with the real implementations. Each asks one question, and the simulator runs the architecture you draw against the requirements you wrote.

01Purpose & invariantsWhat is this for, and what must always be true of it?
02Workload characterizationWho writes, who reads, and in what shapes?
03Data model & on-disk formatWhat does the data look like at rest?
04Core algorithmsHow do the write path and the read path actually work?
05Distribution & replicationHow does this scale out and survive losing a machine?
06Consistency & correctnessUnder concurrency and failure, what is guaranteed?
07Failure modes & recoveryWhat actually happens when each part fails?
08Operational characteristicsCan a human run this at three in the morning?
09Trade-offs & comparisonWhere does this sit against the alternatives?

Primary sources for this problem

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

More in Transactions, Concurrency & Money

Correctness when two writers collide and money is involved: serializability, two-phase commit versus sagas, hold-then-confirm, single-writer matching, and the databases that give you external consistency.

Browse the full problem catalog, or see what the simulator does and does not model.