System Design Interview Framework — Requirements to Deep Dive in 45 Minutes

Overview#

System design interviews are required at senior levels across all major FAANG companies: L5 at Google, E5 at Meta, and SDE II at Amazon. Unlike coding rounds, system design has no single correct answer — interviewers evaluate structure, trade-off reasoning, and communication as much as technical correctness. A candidate who follows a repeatable framework consistently outperforms one who improvises.

Why This Matters#

FAANG system design interviews test whether a candidate can scope a large problem, make reasonable assumptions, design a working architecture, and articulate trade-offs — all in 45 minutes. Most candidates fail system design not because they lack architectural knowledge, but because they dive into the deep dive before establishing requirements, or they design without making trade-offs explicit.

Technical interview tips from Google and Meta engineers consistently emphasize that the requirements and capacity estimation phases — often skipped by anxious candidates — are what signal a senior-level mindset to the interviewer.

The 45-Minute Framework#

Phase 1 — Requirements (5 Minutes)#

Always ask both categories before drawing anything:

Functional requirements — what it does:

• What are the core features? (MVP only, not every possible feature)
• Who are the primary users?
• What does the core API look like?

Non-functional requirements — how it performs:

• Scale: daily active users, requests per second, total data stored
• Latency: p99 read and write targets in milliseconds
• Availability: 99.9 percent vs 99.99 percent (one 9 of difference means very different architecture)
• Consistency: strong vs eventual — what does the user experience if they see stale data?

Example for "Design Twitter":

• Post tweets — 280 characters, text only for MVP
• Follow and unfollow users
• View home feed — top 20 tweets from followees in reverse chronological order
• 300 million DAU, 5,000 tweets written per second
• Feed read latency under 200 milliseconds at p99
• 99.99 percent availability — eventual consistency acceptable for feed

Phase 2 — Capacity Estimation (5 Minutes)#

Show order-of-magnitude reasoning:

Tweets per day: 5,000/sec x 86,400 sec = 432M tweets/day
Storage per tweet: 300 bytes text + metadata = ~500 bytes
Storage per day: 432M x 500 = 216 GB/day
Storage per year: ~80 TB — need distributed storage
 
Read:write ratio: 100:1 (Twitter is read-heavy)
Read QPS: 5,000 x 100 = 500,000 reads/sec
Implication: need read replicas plus aggressive caching

Phase 3 — High-Level Design (10 Minutes)#

Draw the standard boxes and explain the data flow:

Client
  -> CDN (static assets, cached feed)
  -> Load Balancer
  -> App Servers (stateless)
      -> Cache (Redis) for hot reads
      -> Primary DB (writes)
            -> DB Replicas (reads)
            -> Object Store (media)
  -> Message Queue (Kafka) for async fan-out
  -> Feed Service (builds and caches user feeds)

Explain data flow for the primary use case: "User posts tweet, app server validates and writes to primary DB, publishes event to Kafka, background fan-out service pushes tweet ID to each follower's feed cache."

Phase 4 — Deep Dive (15 Minutes)#

Pick 2 to 3 components and go deep. For Twitter:

Fan-out strategy:

• Fan-out on write: precompute feed for each follower immediately. Fast reads, slow writes, storage-intensive. Good for normal users.
• Fan-out on read: compute feed on demand. Slow reads, fast writes. Better for accounts with millions of followers (celebrities).
• Hybrid: fan-out on write for users with fewer than 10,000 followers; fan-out on read for celebrity accounts.

Database choice:

• Tweets: Cassandra — write-heavy, horizontal scaling, no complex joins required
• User data: MySQL — relational, strong consistency needed for authentication and follows
• Feed cache: Redis sorted set with ZADD using timestamp as score, ZREVRANGE for reading

Feed cache design:

• Store only the 500 most recent tweet IDs per user
• On cache miss, reconstruct from DB and re-populate
• TTL of 24 hours for inactive users — do not pre-populate for users who have not logged in recently

Phase 5 — Trade-offs (10 Minutes)#

Make decisions explicit with justifications:

System Design Vocabulary#

Use these terms to signal architectural fluency:

• Horizontal scaling — add more servers of the same type
• Vertical scaling — increase the size of one server
• Sharding — partition a database by key range or hash
• Replication — primary plus replica copies for read scaling and fault tolerance
• CDN — serve static content from edge nodes close to users
• Message queue — decouple producers from consumers asynchronously (Kafka, SQS)
• Rate limiting — token bucket or leaky bucket to protect system capacity
• Consistent hashing — distribute load with minimal key reshuffling when nodes change

Common Mistakes#

• Jumping into the deep dive without establishing requirements first
• Not mentioning the read-to-write ratio — it determines caching and replication strategy
• Choosing one database for everything without discussing trade-offs
• Not making the fan-out decision explicit — it is a core architectural choice
• Running out of time before discussing trade-offs — they signal senior-level reasoning

Interview Tips#

• Open every design with: "Let me start with requirements — functional and non-functional" before touching the whiteboard
• After requirements, say: "Let me do a quick capacity estimate to understand what scale we are designing for"
• Transition to deep dive explicitly: "I want to focus on the feed service and the fan-out strategy — is that the right area to go deep?"
• State trade-offs as explicit choices, not as observations: "I am choosing eventual consistency because the user experience is acceptable with a few seconds of staleness"
• End with one improvement you would make given more time — signals continued thinking

Key Takeaways#

• The 45-minute system design framework: 5 requirements, 5 capacity estimation, 10 high-level design, 15 deep dive, 10 trade-offs
• Requirements phase is non-negotiable — jumping to design without it signals junior-level thinking
• Capacity estimation demonstrates that you can reason about scale, not that you memorize exact numbers
• The hybrid fan-out strategy — write for normal users, read for celebrities — is the standard Twitter design pattern
• System design vocabulary including consistent hashing, CDN, message queue, and sharding signals architectural fluency
• Trade-offs must be explicit decisions with justifications, not observations
• Polyglot persistence — using multiple database types for different data shapes — is expected at senior level
• Always close with one improvement you would make given more time — it signals continued engineering judgment