System Design Interviews

What is actually being tested

A system design interview is not a test of whether you know the right answer. It’s a test of:

1. How you think under ambiguity — do you ask good clarifying questions or barrel forward?
2. Whether you understand trade-offs — can you explain why you chose X over Y?
3. Scale calibration — do you over-engineer a small system or under-spec a large one?
4. Communication — can you drive a technical conversation, not just answer questions?

There is no single correct design for “design Twitter.” There are defensible designs and indefensible designs. Defensible means your choices are justified given your stated constraints.

The framework: 7 steps in 45 minutes

Step 1: Clarify requirements (5 min)

Before touching the whiteboard, ask questions. You’re establishing scope.

Functional requirements: What does the system actually do?

• “Are we designing the posting flow, the feed, or both?”
• “Do users follow each other or is this a public feed?”
• “Do we need to support media uploads?”

Non-functional requirements: What are the constraints?

• “How many daily active users?”
• “What’s the acceptable read latency?”
• “Does this need to be globally distributed?”
• “What’s the consistency requirement — is eventual consistency OK?”

Out of scope: Explicitly state what you’re not building.

“I’ll focus on the post creation and home feed. I’ll skip notifications and search for now unless you want me to cover them.”

This takes 5 minutes. Never skip it. Interviewers who don’t stop you from skipping it are noting it.

Step 2: Capacity estimation (5 min)

Rough numbers anchor your design decisions. You don’t need precision — you need the right order of magnitude.

Example: Design a URL shortener
DAU: 100M users
Write ratio: 1 write per 10 reads
Writes per day: 10M URLs/day → ~116 writes/sec
Reads per day: 100M reads/day → ~1,160 reads/sec

Storage: 100M URLs/day × 100 bytes/URL × 365 days ≈ 3.65 TB/year
→ Needs database with horizontal scaling or sharding in mind
→ Read-heavy: caching is critical

State your assumptions. “I’m assuming 10:1 read-write ratio.” Then move on — don’t spend 15 minutes on arithmetic.

Step 3: High-level design (10 min)

Draw the major components. Start simple:

Client → API Gateway → Application Servers → Database
                              ↓
                           Cache (Redis)
                              ↓
                           CDN (static assets)

Name the components but don’t go deep yet. You’re building a skeleton that you’ll flesh out.

At this stage:

• Define your API (2–3 key endpoints)
• Choose your primary database type and justify it
• Identify where your bottlenecks will be

Step 4: Data model (5 min)

Define the key entities and their relationships.

User: { id, username, email, created_at }
Post: { id, user_id, content, media_url, created_at }
Follow: { follower_id, following_id, created_at }

Identify which fields you’ll query on and note what indexes you’ll need.

Step 5: Deep dive on critical components (15 min)

Your interviewer will steer this. Common areas:

Feed generation: Push vs pull vs hybrid?

• Push (fan-out on write): When a user posts, push to all followers’ feeds immediately. Fast reads, expensive writes for celebrities with millions of followers.
• Pull (fan-out on read): Generate the feed on read by pulling from followees. Slow reads, cheap writes.
• Hybrid: Push for normal users, pull for high-follower users (celebrities).

Database sharding: What’s your shard key?

• Shard by user_id? All posts by one user are co-located — good for user-centric queries, but hot shards for popular users.
• Shard by post_id? Even distribution, but user feed requires scatter-gather across shards.

Caching: What do you cache, what’s the TTL, what’s the eviction strategy?

Replication: Single leader? Multi-leader? Eventual consistency OK?

Step 6: Address bottlenecks and failures (5 min)

Go back through your design and ask: “where does this break at 10× scale?”

• What happens if the database is a bottleneck? → Read replicas, caching, sharding
• What happens if a server crashes? → Load balancer health checks, stateless servers
• What happens if the cache goes down? → Cache warm-up, circuit breakers
• What happens if writes spike? → Message queue to buffer writes, async processing

Step 7: Summarize and invite questions

Briefly recap your design and the key trade-offs you made. Then stop and ask: “Is there a specific component you’d like me to go deeper on?”

The signals that separate levels

Practice template

Before each practice session, answer these before drawing anything:

1. Who uses this? What do they do?
2. What’s the scale? (DAU, reads/sec, writes/sec, storage)
3. What’s the consistency requirement?
4. What are the top 2 bottlenecks likely to be?

If you can answer those four questions before drawing, the design almost writes itself.