How the interviewer opens it
“Design a relational database that scales across servers and supports SQL queries. It must provide strongly consistent transactions and replicate data across regions.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- SQL support
- Data and request scale
- Read and write mix
- Transaction size
- Regions
- Latency
- Consistency
- Availability
- Durability and retries
- Capacity changes and exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Support SQL reads, secondary indexes, joins, and row changes
- Provide strictly serializable transactions across servers
- Replicate data across regions and survive one region failure
- Add capacity and move data while transactions continue
Usually out of scope
- Full compatibility with an existing SQL database
- Online schema changes
- Backup and restore
- Continued service after two region failures
What interviewers ask about
- Transaction order
- Transactions can read and change data on different servers. Their results must match one valid order that also respects real time.
- Transaction outcomes
- Failures can hide a transaction's outcome after several servers accept changes. Retry safety must also survive outcome deletion.
- Regional failures
- Regional links add delay and can fail independently. The database must preserve acknowledged commits without accepting conflicting histories.
- Capacity and query cost
- More servers do not automatically reduce query work. Capacity changes must preserve data ownership and active transactions.
Common mistakes
- Treating consensus as a complete protocol for transactions across servers
- Confusing snapshot isolation with strict serializability
- Promising full availability during a regional partition
- Ignoring the network delay of durable transaction phases
- Ignoring secondary indexes and SQL query costs
- Moving data without preserving active transactions or exclusive ownership
The bar by level
- Senior (L5/E5)
- Specifies replication, serializable concurrency, and atomic commit as separate protocols. Handles coordinator failure, bounded retry guarantees, unique indexes, regional partitions, and safe data moves.
- Staff (L6+/E6+)
- Traces correctness through combined failures, outcome deletion, and capacity changes. Derives latency limits and distributed query costs. Defines recovery rules without unnecessary global coordination.