Shard a Live Database Without Downtime, stage 9 of 9: defend it
Why not a distributed database?
Your interviewer: "This is months of custom work. Why not move to a distributed SQL database like CockroachDB, Spanner or Vitess, which shards for you?"
System so far· 7 parts
Select a component to see what it is responsible for and which state it owns.
- 1Users → Application servers: Requests
- 2Application servers → Monolith Postgres: Reads and writes until cutover
- 3Application servers → Write audit log: Log every write
- 4Backfill and catch-up → Monolith Postgres: Copy existing rows
- 5Backfill and catch-up → Write audit log: Replay logged writes
- 6Backfill and catch-up → Shard hosts: Write rows by shard
- 7Application servers → Connection poolers: Queries by shard
- 8Connection poolers → Shard hosts: Schema on host
- Request / response
- Asynchronous
What you need to know
0 of 1 checks done
Infrastructure choices are often about risk under a deadline rather than which technology is best in general. Moving to a new database means a full migration plus new operational expertise, while the wraparound deadline approaches.
A strong answer still concedes what the alternative offers.
Check
What does a distributed SQL database (CockroachDB, Spanner) genuinely offer over hand-sharding?