System Design Cheat Sheet

Interview steps, quick numbers, availability, load balancing, caching, databases, consistency, replication, queues, APIs, reliability patterns and common designs.

Updated November 5, 2026

Interview steps#

Step	Time	Goal
Requirements	5 min	Features, scale, what matters most
Estimates	5 min	QPS, storage, read-write ratio
API and data	5 min	Endpoints and tables
High-level design	10 min	Draw the request path
Deep dive	15 min	Bottlenecks and failures
Wrap up	5 min	Trade-offs and next steps

Quick numbers#

Item	Value
Seconds in a day	About 100,000 (86,400)
1 million requests a day	About 12 per second
Peak traffic	2 to 5 times the average
Memory read	100 ns
SSD read	100 microseconds
Round trip in a data centre	0.5 ms
Continent to continent	150 ms

Availability#

Target	Downtime a year
99%	3.65 days
99.9%	8.8 hours
99.99%	53 minutes
99.999%	5.3 minutes

Chained parts multiply: 99.9% × 99.9% = 99.8%.

When to reach for what#

Problem	Tool
Too many reads	Cache, read replicas, CDN
Too many writes	Sharding, queues, batching
Slow queries	Indexes, denormalise
Slow requests	Queue the work, go async
Traffic spikes	Queue, autoscaling, rate limits
Single point of failure	Redundancy, failover
Large files	Object storage and CDN
Full-text search	Search engine
Global users	CDN, regional deployment

Load balancing#

Algorithm	Good for
Round robin	Similar requests
Least connections	Requests of varied length
IP hash	Keeping a client on one server

Layer 4 routes by IP and port. Layer 7 routes by URL and headers.

Caching#

Strategy	On write
Cache-aside	Update the database, delete the cache entry
Write-through	Update cache and database together
Write-back	Update the cache, and the database later

Problem	Fix
Stampede	Lock, early refresh
Avalanche	Random TTLs
Penetration	Cache "not found", Bloom filter
Hot key	Local cache, copies

Databases#

Type	Examples	Use for
Relational	PostgreSQL, MySQL	Transactions, joins
Key-value	Redis, DynamoDB	Sessions, simple lookups
Document	MongoDB	Flexible records
Wide-column	Cassandra	Huge write volumes
Search	Elasticsearch	Text search
Graph	Neo4j	Relationships

Consistency#

CAP: during a partition, choose consistency or availability.
Quorum: R + W must be greater than N for current reads.
Strong: payments, inventory.
Eventual: feeds, likes, counters.

Replication and sharding#

Replicas add read capacity, not write capacity.
Asynchronous replication means lag.
A shard key needs many values, and an even spread.
Consistent hashing moves few keys when servers change.

Queues#

At-least-once delivery means that consumers must be idempotent.
Use a dead-letter queue for repeated failures.
Queue: tasks. Log (Kafka): event streams and replay.

API#

Name resources, and use HTTP methods.
Use cursors for feeds.
Use idempotency keys for payments.
Status codes: 200, 201, 400, 401, 403, 404, 429, 500, 503.

Reliability patterns#

Pattern	Purpose
Timeout	Do not wait forever
Retry with backoff and jitter	Survive brief failures
Circuit breaker	Stop calling a failing service
Bulkhead	Contain a failure
Load shedding	Drop less important work
Graceful degradation	Offer a reduced service

Rate limiting#

Algorithm	Note
Fixed window	Simple, but allows bursts at edges
Sliding window	Accurate
Token bucket	Allows controlled bursts

Common designs#

System	Key ideas
URL shortener	Base62 IDs, cache, redirects
Chat	WebSockets, sequence numbers, wide-column store
News feed	Fan-out, hybrid for celebrities
Video	Chunked upload, transcoding, CDN
Ride-sharing	Geo index, in-memory locations, atomic matching
Ticket booking	Atomic holds, unique constraint, waiting room

Want the full explanations? Go to the Learn System Design course →