System Design Interview Framework — Requirements to Deep Dive

The 45-Minute System Design Framework

0:00 — 0:05  Requirements (functional + non-functional)
0:05 — 0:10  Capacity estimation
0:10 — 0:20  High-level design
0:20 — 0:35  Deep dive (2-3 components)
0:35 — 0:45  Trade-offs + bottlenecks + improvements

Step 1 — Requirements (5 min)

Always ask:

Functional:

• What are the core features? (MVP only)
• Who are the users?
• What does the API look like?

Non-functional:

• Scale: DAU, requests/sec, data size
• Latency: p99 read/write targets
• Availability: 99.9% vs 99.99%
• Consistency: strong vs eventual

Example for "Design Twitter":

Functional:
- Post tweets (text, 280 chars)
- Follow/unfollow users
- View news feed (top 20 tweets from followees)

Non-functional:
- 300M DAU, 5000 tweets/sec written
- Feed read: < 200ms p99
- 99.99% availability
- Eventual consistency acceptable for feed

Step 2 — Capacity Estimation (5 min)

Quick math — show you can reason about scale:

Tweets/day: 5000/sec × 86400 = 432M/day
Storage/tweet: 300 bytes text + metadata = ~500 bytes
Storage/day: 432M × 500 = 216 GB/day
Storage/year: ~80 TB/year → need distributed storage

Read:write ratio: 100:1 (Twitter is read-heavy)
Read QPS: 5000 × 100 = 500K/sec → need read replicas + caching

Step 3 — High-Level Design (10 min)

Draw these boxes:

Client → Load Balancer → [App Servers] → [Cache (Redis)]
                                      → [DB (primary)]
                                              ↓
                                      [DB Replicas]
                                              ↓
                                      [Object Store (S3)]

Explain data flow for the main use case: "User posts tweet → App server validates → writes to DB → invalidates feed cache → background job fans out to followers"

Step 4 — Deep Dive (15 min)

Pick 2-3 hard components and go deep:

Fan-out on write vs fan-out on read:

• Write: precompute feed for each follower (fast read, slow write, storage intensive)
• Read: compute feed on demand (slow read, fast write) — better for celebrities with 100M followers
• Hybrid: fan-out on write for normal users, read on demand for high-follower accounts

Database choice:

• Tweets: NoSQL (Cassandra) — write-heavy, horizontal scaling, no complex joins
• User data: SQL (MySQL) — relational, consistency for follows/auth
• Feed cache: Redis sorted set (ZADD with timestamp as score)

Step 5 — Trade-offs (10 min)

Always discuss:

System Design Vocabulary

Use these terms to signal fluency:

• Horizontal scaling — add more servers
• Vertical scaling — bigger server
• Sharding — split DB by key range or hash
• Replication — primary + replica for reads
• CDN — serve static content from edge
• Message queue — decouple producers/consumers (Kafka)
• Rate limiting — token bucket, leaky bucket
• Consistent hashing — distribute load with minimal reshuffling