The round in one line each
- 1.Requirements: core features, what's out, and the numbers
- 2.Estimation: peak requests a second, storage, read to write ratio
- 3.API and data model: endpoints, tables, the lookup key
- 4.High-level design: simple and complete; walk a read and a write
- 5.Deep dives: the hard part, two options, a choice and its cost
- 6.Wrap-up: what breaks at 10x and how you would know
The full version, with a time budget for each step: how to prepare for a system design interview.
Latency numbers
Orders of magnitude, not exact values. What matters is which column a number falls in.
| Operation | Rough time |
|---|---|
| Read from CPU cache | about 1 ns |
| Read from main memory | about 100 ns |
| Random read from an SSD | about 100 µs |
| Round trip inside one data center | about 0.5 ms |
| Read 1 MB sequentially from an SSD | under 1 ms |
| Disk seek on a spinning drive | about 10 ms |
| Round trip across a continent | about 50 ms |
| Round trip across the world | about 150 ms |
Rough capacity of one machine
Starting assumptions to say out loud and adjust. Real numbers depend on hardware, payload size and how much work each request does.
| Component | Planning number |
|---|---|
| One stateless API server | hundreds to a few thousand requests a second, depending on the work per request |
| One relational database primary | a few thousand to about ten thousand simple writes a second; more reads, and more again from replicas |
| One Redis instance | on the order of 100,000 simple operations a second |
| One Kafka partition | tens of MB a second; a topic scales by adding partitions |
| One server holding WebSocket connections | tens of thousands of mostly idle connections, more with tuning |
Estimation shortcuts
| Quantity | Shortcut |
|---|---|
| Seconds in a day | 86,400, call it 100,000 |
| 1 million requests a day | about 12 a second |
| 1 billion requests a day | about 12,000 a second |
| Peak traffic | often 2 to 3 times the average for consumer apps; say your assumption |
| Storage | writes a day × size of each × days kept × copies (often 3) |
| Bandwidth | requests a second × size of each response |
| Powers of ten | thousand = KB, million = MB, billion = GB, trillion = TB |
| Thing | Rough size |
|---|---|
| An ID or timestamp | 8 bytes; a UUID is 16 bytes, 36 as text |
| A short text post with metadata | about 1 KB |
| A compressed photo | a few hundred KB to a few MB |
| One minute of 1080p video | tens of MB |
Worked examples and the common traps: back-of-the-envelope estimation.
Which building block for which problem
Every block solves one problem and brings a new one. Say both.
Spread traffic across servers
A load balancer in front of stateless servers
Costs: Health checks, sticky sessions, and the balancer itself as a single point of failure.
The same data is read again and again
Costs: Stale reads, invalidation, and a stampede when a hot entry expires.
Static files and media for users everywhere
Costs: Purging and cache keys; it does nothing for personalized responses.
Data or writes outgrow one machine
Costs: Hot shards, cross-shard queries, and resharding later.
Add or remove nodes without moving everything
Consistent hashing with virtual nodes
Costs: More moving parts than simple modulo hashing.
Survive a dead node and scale reads
Replication with a leader and followers
Costs: Replication lag, failover, and split brain.
One key gets a huge share of traffic
Split the key, cache it close to readers, or aggregate before writing
Costs: Reads have to merge the pieces.
Smooth bursts and decouple services
Costs: Duplicates, ordering, and messages that fail forever.
Many consumers, replay from the past
Costs: Partitioning decides ordering and parallelism.
Retries must not charge twice
Costs: Extra writes, and the guarantee only lasts as long as you keep the keys.
Write to the database and publish an event, reliably
Costs: A relay process and at-least-once delivery downstream.
A transaction across several services
A saga with compensating steps
Costs: Intermediate states are visible; compensations must be designed.
Atomic commit across a few databases you control
Costs: Blocking when the coordinator fails, and higher latency.
Only one worker at a time
Costs: Clocks and pauses; the lock alone isn't safe without the token.
Find things near a location
Costs: Edge cells, and uneven density between city and countryside.
Have we seen this before, with little memory
Costs: False positives, and no deletes without a counting variant.
Stop abuse and protect capacity
Token bucket or sliding window rate limiting
Costs: Shared counters across servers, and fairness between users.
Push updates to clients
WebSockets or server-sent events
Costs: Long-lived connections to route, scale and reconnect.
Full history, or rebuild state at any point
Costs: Schema evolution of events, and snapshots for speed.
Reads and writes need different shapes
CQRS with a separate read model
Costs: The read side is eventually consistent.
Consistency in three lines
- During a network partition you choose: refuse some requests (consistent) or answer with possibly stale data (available).
- Without a partition you still trade latency for consistency: waiting for more replicas is slower but safer.
- Pick per feature, not per system. Payments and bookings want strong consistency; likes and view counts can be eventual.
More: CAP theorem, eventual consistency, SQL vs NoSQL.
The wrap-up checklist
- What breaks first at 10x traffic, and what you would change.
- Single points of failure, and what happens when each one dies.
- What happens on a retry, a duplicate message, or a timeout.
- The metrics and alerts that tell you something is wrong.
- The decision you would revisit with more time.
Questions people ask
What numbers should I memorize for a system design interview?
A handful: seconds in a day (about 100,000), the memory, SSD, data center and cross-world latencies by order of magnitude, and rough per-server capacities. Interviewers care that your numbers are in the right range and that you use them to make decisions, not about exact values.
Is it OK to use a cheat sheet in a system design interview?
Not during the interview itself. Use it while you practice, until the numbers and building blocks come to mind on their own. In the round, say your assumptions out loud; interviewers expect rough figures.
How precise do estimates need to be?
Within a factor of a few. Round aggressively, like 100,000 seconds in a day, and say what each number means for the design: whether it fits on one machine, needs a cache, or needs sharding.