Two years ago, system design interviews terrified me. The questions felt impossibly open-ended. "Design Twitter." Cool, where do I even start? I'd ramble about databases and load balancers while the interviewer's eyes glazed over.

Then I developed a framework. Not a magic trick - just a structured approach that works for any system design question. I've used it in interviews at Google, Meta, Amazon, and multiple startups. It works.

The 5-Step Framework

Step 1: Requirements & Constraints

This is where most people mess up. They hear "Design Instagram" and start drawing boxes. Don't. Ask questions first.

Step 2: Capacity Estimation

Back-of-envelope math. You don't need exact numbers - you need the right order of magnitude. This tells you if you need 1 server or 1000.

Users: 500M DAU
Posts per day: 50M new posts
Average post size: 500KB (compressed image)

Storage (daily): 50M * 500KB = 25TB/day
Storage (yearly): 25TB * 365 = ~9PB/year

Read requests: Assume 100 reads per user per day
  500M * 100 = 50B reads/day
  = ~580K reads/second

Write requests: 50M posts/day
  = ~580 writes/second

Ratio: Read-heavy (~1000:1 read:write)

Numbers to memorize:

• • 1 day = 86,400 seconds ≈ 100K seconds
• • 1 million requests/day ≈ 12 requests/second
• • 1 byte = 8 bits
• • 1KB = 1000 bytes, 1MB = 1000KB, 1GB = 1000MB, 1TB = 1000GB
• • Typical server handles ~1000-10000 QPS depending on complexity

Step 3: High-Level Design

Now you draw. Start simple. Add complexity only when needed.

API Design

Define your main APIs before diving deeper. This shows you're thinking about interfaces, not just infrastructure.

POST /posts
  body: { image_url, caption, location }
  returns: { post_id, created_at }

GET /feed?user_id={id}&cursor={cursor}&limit=20
  returns: { posts: [...], next_cursor }

POST /follow
  body: { follower_id, followee_id }

GET /users/{id}/posts?cursor={cursor}&limit=20

Step 4: Deep Dive

The interviewer will ask you to go deeper on specific areas. Be ready to discuss:

Users Table:
  user_id (PK), username, email, created_at

Posts Table:
  post_id (PK), user_id (FK), image_url,
  caption, created_at, location

Follows Table:
  follower_id, followee_id, created_at
  (composite PK or separate index)

Step 5: Bottlenecks & Trade-offs

Always end by discussing what could break and how you'd address it. This shows senior-level thinking.

Common System Design Questions

How to Practice

• Study one system per day. Read about the design, draw the diagram, explain it out loud.
• Practice on a whiteboard or drawing tool. The physical act of drawing while explaining is different from just reading.
• Time yourself. 45 minutes is standard. If you can't cover the basics in 45 min, you're going too deep too early.
• Mock interviews are essential. System design is interactive. You need someone asking questions and poking at your design.

I use LastRound AI for system design practice. It asks follow-up questions like a real interviewer: "What happens if this service goes down?" "How would you handle 10x traffic?" Helps me practice thinking on my feet.

Resources I Used

• • Designing Data-Intensive Applications by Martin Kleppmann - The bible. Dense but essential.
• • System Design Interview by Alex Xu - Great for structured prep. Covers common questions.
• • ByteByteGo - Good visuals and explanations.
• • Actual engineering blogs - How Netflix, Uber, Meta actually built their systems.

Final Thoughts

System design interviews are less about having the "right" answer and more about demonstrating structured thinking. Use a framework, ask questions, explain your trade-offs, and be honest about what you don't know.

The more systems you study, the more patterns you'll recognize. And patterns are what make these interviews manageable.

Last updated: January 2026