system-design

Cheat Sheets

The whole repo, compressed into scannable reference tables for the night before an interview. This is not where you learn these things — it’s where you revise them once you already understand them. Skim it before a mock or an interview to reload everything into working memory.

Time to read: ~10 minutes to skim; keep it open during revision

🚨 Use this to refresh, not to learn. A cheat sheet is dangerous as a first exposure (you’ll memorize without understanding). Once you’ve done the chapters and case studies, this reloads it fast.

---

The interview framework (the spine)

1. Requirements   (5m)  — functional + non-functional; interpret NFRs; scope out
2. Estimation     (5m)  — QPS, storage, bandwidth; use the numbers
3. High-level     (10m) — client → LB → services → stores; both paths; API + data model
4. Deep dives     (15m) — the component that matters; options + trade-off + choice; edge cases
5. Bottlenecks    (5m)  — what breaks next, how to scale it
6. Wrap up        (5m)  — summarize + trade-offs + what's left

🚨 Clarify before solutioning · estimate with purpose · justify every choice · drive · connect back to requirements. → Framework

---

Estimation anchors

Thing	Value
Seconds/day	~86,400 → 10⁵
Seconds/month	~2.6M
Seconds/year	~31.5M → 3×10⁷
Peak factor	~2–5× average
Char	1 byte · Tweet ~300 B · Web page ~1 MB · Photo ~1–5 MB · 1 min 1080p ~50 MB
1 server	~10K–100K QPS (simple)
Redis node	~100K+ ops/s
SQL primary	~a few K writes/s

Latency (Jeff Dean-ish): L1 ~1 ns · RAM ~100 ns · SSD read ~100 µs · same-DC RTT ~0.5 ms · disk seek ~10 ms · cross-continent RTT ~100–150 ms. → Latency Numbers

Formulas: QPS = actions/day ÷ 10⁵ · Storage = objects × size × retention · Bandwidth = QPS × payload · Servers = total QPS ÷ per-server QPS (+ margin). → Estimation Drills

---

CAP / consistency in one glance

• CAP: under a partition, pick C (refuse, stay correct) or A (serve, maybe stale). PACELC: else, latency vs consistency.
• CP → money, inventory, config, locks. AP → feeds, caches, DNS, presence.
• Strong consistency: every read sees latest write; costs latency/availability.
• Eventual: fast, available; app tolerates staleness.
• Quorum: R + W > N → read sees latest write. → CAP & PACELC · Consistency Models

---

Building blocks: when to use

| Need | Reach for | | — | — | | Read-heavy, repeated reads | Cache (Redis) | | Static/media to global users | CDN | | Decouple / absorb bursts / async | Message queue / log (Kafka) | | Large blobs (images, video, files) | Object storage (S3) + CDN | | Scale reads | Replicas (+ cache) | | Scale writes / data size | Shard | | Distribute keys over changing nodes | Consistent hashing + vnodes | | “Is it in the set?” cheaply | Bloom filter | | “What’s nearby?” | Geospatial index (geohash/S2) | | Full-text search | Inverted index (Elasticsearch) | | Sortable distributed IDs | Snowflake | | Real-time bidirectional | WebSocket · one-way push → SSE | | Rank/top-K | Sorted set (Redis ZSET) | → Component Drills

---

SQL vs NoSQL

	SQL	NoSQL
Best for	Transactions, joins, strong consistency	Scale, flexible schema, simple access
Consistency	Strong (ACID)	Often eventual
Scaling	Harder (vertical + shard)	Horizontal by design
Pick when	Money, relational, complex queries	Massive scale, KV/document/wide-column access

Storage engines: B-tree = read-optimized (SQL) · LSM-tree = write-optimized (Cassandra, metrics/logs).

---

The recurring case-study patterns

1. Read-heavy → cache + precompute
2. Feeds → fan-out (write/read) + hybrid for celebrities
3. Big payloads → metadata in DB, blobs in object storage + CDN
4. Don’t oversell → reserve-then-confirm with TTL
5. Recommenders/search/feeds → candidate generation → ranking
6. ML serving → precomputed feature store + fast online
7. Analytics/trading/payments → event log as source of truth; replay
8. Reliability → at-least-once + idempotency = exactly-once effect
9. Correctness → strong consistency only for money & stock; eventual elsewhere
10. Location → geospatial index + partition by geography
11. Real-time → stateful connections (WS/UDP) + presence + reconnect sync
12. Fresh + exact → batch (exact) + stream (fresh) two-speed → Case Studies

---

Trade-off one-liners (say these out loud)

• Strong vs eventual consistency — what does stale data cost here?
• Latency vs throughput — batching trades one for the other.
• SQL vs NoSQL — transactions/relational vs scale/flexible access.
• Normalize (write-easy) vs denormalize (read-fast).
• Sync (simple, coupled) vs async (decoupled, eventual).
• Fan-out write (fast reads) vs read (cheap writes) → hybrid.
• At-least-once + idempotency vs at-most-once.
• Monolith (simple) vs microservices (independent, complex) — start monolith.
• Fail-open (availability) vs fail-closed (safety).
• Scale up (simple, ceiling) vs scale out (unlimited, complex). → Trade-off Drills

---

Scaling ladder (1 → 1B users)

1 server → split app/DB → add cache → add read replicas → load balancer + many app servers
→ CDN for static → shard the DB → microservices → multi-region

🚨 Each stage fixes the previous bottleneck; almost every stage is about the database; don’t skip ahead. → 1 → 1B

---

Reliability & performance quick hits

• Hot key: replicate the key / in-process cache / CDN — hashing distributes keys, not load.
• Thundering herd: request coalescing + TTL jitter + backoff.
• Retries: exponential backoff + jitter; cap; circuit breaker; idempotency.
• Bound every resource: connection pools (PgBouncer), timeouts, bulkheads, rate limits.
• Idempotency key on every retryable mutating request. → Performance · Resilience Patterns

---

The night-before checklist

• I can recite the 6-step framework and time-box it.
• Estimation anchors (10⁵ s/day, latency numbers) are automatic.
• I can pick the right building block and justify it (and the alternative).
• I can state 10 trade-offs both ways.
• I know the 12 recurring patterns and which case study each maps to.
• I have my behavioral/STAR stories ready.
• I’ve done a full mock this week and know my weakest dimension.

🚨 Then stop cramming and sleep. A rested brain outperforms a crammed one in a design interview.

---

Further reading

• Every section links to its full chapter — use this to navigate back to depth.
• Reading List · Part 15 index
• The Framework · Case Studies · Practice

This site is open source. Improve this page.