Problems
#05Build a Spanner-style strongly consistent distributed database
stub
External consistency at global scale. Build a database where a Paxos group per shard agrees on every write, TrueTime turns a clock interval into a serialization point, and 2PC across shards stays correct because everyone honors the same wait. Feel why CockroachDB and YugabyteDB diverge from Spanner precisely where TrueTime sits.
Saved on this device
Build a Spanner-style strongly consistent distributed database. External consistency at global scale. Build a database where a Paxos group per shard agrees on every write, TrueTime turns a clock interval into a serialization point, and 2PC across shards stays correct because everyone honors the same wait. Feel why CockroachDB and YugabyteDB diverge from Spanner precisely where TrueTime sits.
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: Corbett et al. — Spanner: Google's Globally-Distributed Database (OSDI 2012) · Bacon et al. — Spanner: Becoming a SQL System (SIGMOD 2017) · Google Cloud Spanner whitepaper — TrueTime and external consistency · Daniel Abadi — Correctness Anomalies Under Serializable Isolation · CockroachDB blog — Living Without Atomic Clocks (HLC vs TrueTime) · YugabyteDB docs — Distributed transactions and consistency
Paxos / Raft group per shard (one consensus layer per range)
TrueTime API — bounded clock uncertainty as a primitive
commit wait — pay the uncertainty to publish a write at a real instant
external consistency vs linearizability vs serializability
2PC across shards layered over per-shard consensus
read-only transactions at a snapshot timestamp (no locks)
directory / range-based sharding + dynamic splits
snapshot reads vs strong reads vs stale reads
schema change as a globally-coordinated transaction
Paxos leader leases tied to TrueTime
No scenes authored for this problem yet.