Sharded SQL (Vitess-style)
A query router fans SQL across range shards via a topology service — with scatter-gather reads, 2PC for cross-shard writes, and a live range split in progress.
What this design does
How YouTube scaled MySQL and how PlanetScale works today: applications keep speaking plain SQL to a router, which consults the shard map, pushes single-shard queries to one primary, and scatter-gathers the rest. The diagram includes the operationally interesting moment most drawings skip — a shard mid-split, backfilling its new neighbor before the cutover.
The patterns it composes
- Directory / lookup sharding — a topology service owns the key-range → shard map
- Scatter-gather queries — cross-shard SELECTs fan out and merge; single-shard stays cheap
- Range split / merge + auto-rebalancing — hot ranges split and migrate without downtime
- Two-phase commit — the (expensive) escape hatch for cross-shard writes
- Hot-shard mitigation — the split in the diagram is the cure for a hot range
Import it, attach your own numbers, and verify the design against failures — or read the engineering notes.