# Design a distributed SQL database like Spanner: system design interview question

> SQL across servers: transaction order, regional failures, distributed query costs, and capacity changes during active transactions.

Source: https://sysround.com/questions/design-distributed-sql-database-like-spanner
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## 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."

## 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

## 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 probe

### 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:** 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+:** Traces correctness through combined failures, outcome deletion, and capacity changes. Derives latency limits and distributed query costs. Defines recovery rules without unnecessary global coordination.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=distributed-sql-database


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.