System Design Series — Page 7

The Interview Framework

Q: How long should I spend on each part of a system design interview?

Use the 3-5-5-10-5-3-3 split: Requirements (3-5 min), Estimation (2-3 min), Storage (3-4 min), High-Level Design (5-7 min), API Design (3-4 min), Detailed Design (10-12 min), Evaluation (3-4 min). The detailed design gets the most time because that's where you demonstrate senior-level thinking. Adjust based on interviewer signals — if they want to go deep on estimation, spend more time there.

Q: Should I draw a diagram in a system design interview?

Always. Even on a video call with no whiteboard, share your screen and use a simple drawing tool (Excalidraw, draw.io). Diagrams make your thinking visual, help the interviewer follow along, and give you a reference to point to. Start with 5-7 boxes maximum — you can add detail as you go.

Q: What if I don't know a specific technology the interviewer mentions?

Be honest: 'I haven't used X directly, but I understand it solves [problem]. I've used Y which is similar.' Interviewers are testing your understanding of concepts, not memorization of specific tools. Knowing why you'd use a message queue matters more than knowing Kafka's exact API.

Q: How do I handle 'what if' follow-up questions?

These are the interviewer testing your depth. Common patterns: 'What if scale increases 10x?' → discuss sharding, caching, CDN. 'What if a component fails?' → discuss redundancy, circuit breakers, graceful degradation. 'What about consistency?' → discuss CAP tradeoffs. Always connect back to your requirements.

Q: Should I mention specific technologies like Redis, Kafka, or DynamoDB?

Yes, but always with justification. 'I'd use Redis for caching because we have a 100:1 read:write ratio and Redis handles 100K+ ops/sec on a single node' is strong. 'I'd use Redis because it's fast' is weak. The technology name is less important than demonstrating you understand why it fits.

Q: How important is back-of-the-envelope estimation?

Very important at FAANG/big tech companies. It separates people who 'know system design concepts' from people who can 'actually design systems.' The key insight: whether you need 1K or 1M QPS completely changes the architecture. You don't need exact math — order of magnitude is sufficient. Practice the formulas: QPS = DAU × actions / 86,400.

Q: What's the difference between a junior and senior system design answer?

Junior: describes components ('we have a database and a cache'). Senior: explains decisions ('we use cache-aside with Redis because our read:write ratio is 100:1, and we can tolerate stale data for 30 seconds based on our consistency requirements'). Senior answers always connect decisions to requirements and discuss tradeoffs proactively.

Q: How many system design problems should I practice?

Focus on 8-10 diverse problems that cover different patterns: URL shortener (read-heavy), chat system (real-time), news feed (fan-out), notification system (queues), file storage (large objects), rate limiter (distributed state). Understanding the patterns matters more than memorizing solutions — most interview questions are variations of these core patterns.

Q: What if I run out of time?

If you're running low at the 30-minute mark, skip to evaluation: 'I want to make sure I cover the tradeoffs and potential improvements.' Showing self-awareness and prioritization is more impressive than rushing through a half-finished detailed design. An interviewer would rather see a solid high-level design with good tradeoff analysis than a detailed design that's incomplete.

Q: Is the RESHADED framework the only way to structure an answer?

No — there's also DDIA-style (data model → API → scale), and simple 4-step approaches (requirements → design → deep dive → evaluate). RESHADED is comprehensive and covers all the bases that interviewers look for. Use whatever framework feels natural, but make sure you cover: requirements, estimation, schema, high-level design, API, detailed design, and tradeoffs.

How to structure a system design answer in 45 minutes. The RESHADED framework, back-of-the-envelope estimation, latency numbers, and the six mistakes that cost people offers.

45 min

Average Interview

RESHADED Steps

Estimation Scenarios

Latency Numbers

Most people fail system design interviews not because they don't know the concepts — but because they don't know how to present them. You have 45 minutes. The interviewer is evaluating your ability to break down ambiguity, make decisions under pressure, communicate tradeoffs, and demonstrate depth where it matters. That's a performance skill, not just a knowledge test.

This page teaches the meta-skill: how to structure your answer. We'll walk through the RESHADED framework (8 steps, applied to a real example), practice estimation with 6 scenarios from Twitter to Uber, memorize the latency numbers that shape every architecture, and dissect the 6 mistakes that cost people offers.

If you haven't read the series yet, start with System Design 101 for the building blocks, then The Data Layer and Distributed Systems for the concepts you'll apply. This page teaches you how to wield them in 45 minutes.

The RESHADED Framework — 8 Steps, 45 Minutes

Every strong system design answer follows a structure. RESHADED gives you one: Requirements, Estimation, Storage, High-level, API, Detailed, Evaluation, Distinctive. Each step builds on the last. Skip one and the interviewer notices.

Requirements

3–5 min

Clarify what you're building. Separate functional requirements (what it does) from non-functional requirements (how well it does it). This is the most important step — a wrong assumption here derails the entire design.

What To Do

1.Ask: Who are the users? How many?
2.List functional requirements (core features only — 3-5 max)
3.List non-functional requirements (latency, availability, consistency, durability)
4.Identify scale: DAU, read:write ratio, data volume
5.State assumptions explicitly — don't guess silently

Example: URL Shortener

Functional: shorten URL, redirect to original, custom aliases optional, link expiry. Non-functional: 99.99% availability, <100ms redirect latency, 100:1 read:write ratio, 100M new URLs/day.

Common Mistake

Jumping straight to architecture without asking a single question. Interviewers expect you to clarify — it's not a test of telepathy.

Step 1 of 8

Time Allocation (45 min interview)

Detailed Design gets the most time — that's where senior thinking shows

The framework is the skeleton. Estimation is the muscle.

You know the structure. But when the interviewer asks “how many servers do we need?” — you need to answer with numbers, not vibes. Back-of-the-envelope estimation takes 2-3 minutes and completely changes your architecture. The difference between 10K QPS and 1M QPS is the difference between one server and a distributed system.

Estimation Gym — Practice Back-of-the-Envelope Math

Estimation is a distinct interview skill. The goal isn't exact numbers — it's order of magnitude. Is it 10K QPS or 1M QPS? That changes everything. Practice with these 6 real-world scenarios using the formula: QPS = DAU × actions / 86,400.

Twitter has 400M DAU. Each user views 200 tweets and posts 2 tweets per day. Calculate read and write QPS.

DAU400M

Tweets read/user/day200

Tweets posted/user/day2

Try to estimate the answer before revealing the solution

Estimation is only as good as your baseline numbers

To estimate “can one Redis node handle this?” you need to know that Redis does ~100K-500K ops/sec. To decide between caching and hitting the database, you need to know that L1 cache is 0.5ns and a cross-datacenter round trip is 500μs — a million times slower. These numbers are the vocabulary of system design.

Numbers to Know — The Cheat Sheet

System design estimation relies on a small set of memorized numbers. Jeff Dean's latency numbers, powers of 2, and throughput baselines for common systems. Knowing these lets you estimate any system's requirements in under 3 minutes.

Latency Numbers Every Programmer Should Know

Originally compiled by Jeff Dean at Google. L1 cache to cross-continent spans a 300-million-x difference. These numbers shape every caching, replication, and architecture decision.

L1 cache reference

0.5 ns

L2 cache reference

7 ns

Main memory reference

100 ns

SSD random read

16 μs

Read 1 MB from memory

250 μs

Read 1 MB from SSD

1 ms

Read 1 MB from HDD

20 ms

Round trip within datacenter

0.5 ms

Round trip CA → Netherlands

150 ms

memory

disk

network

Powers of 2 — Quick Size Reference

2^101,0241 Thousand (1 KB)

2^201,048,5761 Million (1 MB)

2^301,073,741,8241 Billion (1 GB)

2^401,099,511,627,7761 Trillion (1 TB)

2^501,125,899,906,842,6241 Quadrillion (1 PB)

Quick Reference — Numbers for Estimation

Click a card to reveal the value. Test yourself.

Knowing the right answer isn't enough if you deliver it wrong

You can know every concept, nail the estimation, and still fail the interview. System design is a communication exercise as much as a technical one. The difference between a “hire” and a “no hire” often comes down to how you present — not what you present. Here are the six patterns that trip up even experienced engineers.

6 Mistakes That Cost People Offers

These aren't edge cases. They're the most common reasons candidates fail system design interviews, based on feedback from interviewers at Google, Meta, Amazon, and Stripe. Each one is preventable.

Not Clarifying RequirementsCritical

Jumping straight into drawing boxes without asking a single question. You're solving a problem you invented, not the one the interviewer intended.

What It Looks Like

Interviewer: 'Design a chat system.' You: 'Okay, so we have WebSocket servers...' — you never asked: 1-to-1 or group? Message history? Read receipts? Presence? File sharing?

The Fix

Spend the first 3-5 minutes ONLY on requirements. Ask at least 5 clarifying questions. Write the requirements on the board.

Continue the Series

You have the framework. Now apply it — the Netflix case study walks through a complete system design using every concept from the series.

← Page 6: Monitoring & Observability Page 1: System Design 101 Page 8: Design Netflix →

1. Overview 2. Network 3. Data 4. Distributed 5. Security 6. Monitoring 8. Netflix7. Interview (You are here)

Frequently Asked Questions

How long should I spend on each part of a system design interview?+

Use the 3-5-5-10-5-3-3 split: Requirements (3-5 min), Estimation (2-3 min), Storage (3-4 min), High-Level Design (5-7 min), API Design (3-4 min), Detailed Design (10-12 min), Evaluation (3-4 min). The detailed design gets the most time because that's where you demonstrate senior-level thinking. Adjust based on interviewer signals — if they want to go deep on estimation, spend more time there.

Should I draw a diagram in a system design interview?+

Always. Even on a video call with no whiteboard, share your screen and use a simple drawing tool (Excalidraw, draw.io). Diagrams make your thinking visual, help the interviewer follow along, and give you a reference to point to. Start with 5-7 boxes maximum — you can add detail as you go.

What if I don't know a specific technology the interviewer mentions?+

Be honest: 'I haven't used X directly, but I understand it solves [problem]. I've used Y which is similar.' Interviewers are testing your understanding of concepts, not memorization of specific tools. Knowing why you'd use a message queue matters more than knowing Kafka's exact API.

How do I handle 'what if' follow-up questions?+

These are the interviewer testing your depth. Common patterns: 'What if scale increases 10x?' → discuss sharding, caching, CDN. 'What if a component fails?' → discuss redundancy, circuit breakers, graceful degradation. 'What about consistency?' → discuss CAP tradeoffs. Always connect back to your requirements.

Should I mention specific technologies like Redis, Kafka, or DynamoDB?+

Yes, but always with justification. 'I'd use Redis for caching because we have a 100:1 read:write ratio and Redis handles 100K+ ops/sec on a single node' is strong. 'I'd use Redis because it's fast' is weak. The technology name is less important than demonstrating you understand why it fits.

How important is back-of-the-envelope estimation?+

Very important at FAANG/big tech companies. It separates people who 'know system design concepts' from people who can 'actually design systems.' The key insight: whether you need 1K or 1M QPS completely changes the architecture. You don't need exact math — order of magnitude is sufficient. Practice the formulas: QPS = DAU × actions / 86,400.

What's the difference between a junior and senior system design answer?+

Junior: describes components ('we have a database and a cache'). Senior: explains decisions ('we use cache-aside with Redis because our read:write ratio is 100:1, and we can tolerate stale data for 30 seconds based on our consistency requirements'). Senior answers always connect decisions to requirements and discuss tradeoffs proactively.

How many system design problems should I practice?+

Focus on 8-10 diverse problems that cover different patterns: URL shortener (read-heavy), chat system (real-time), news feed (fan-out), notification system (queues), file storage (large objects), rate limiter (distributed state). Understanding the patterns matters more than memorizing solutions — most interview questions are variations of these core patterns.

What if I run out of time?+

If you're running low at the 30-minute mark, skip to evaluation: 'I want to make sure I cover the tradeoffs and potential improvements.' Showing self-awareness and prioritization is more impressive than rushing through a half-finished detailed design. An interviewer would rather see a solid high-level design with good tradeoff analysis than a detailed design that's incomplete.

Is the RESHADED framework the only way to structure an answer?+

No — there's also DDIA-style (data model → API → scale), and simple 4-step approaches (requirements → design → deep dive → evaluate). RESHADED is comprehensive and covers all the bases that interviewers look for. Use whatever framework feels natural, but make sure you cover: requirements, estimation, schema, high-level design, API, detailed design, and tradeoffs.

Sources & References

Jeff Dean — Numbers Every Programmer Should Know (Stanford CS295)
Alex Xu — System Design Interview (Volume 1 & 2)
Designing Data-Intensive Applications — Martin Kleppmann (O'Reilly)
Google SRE Book — Site Reliability Engineering (sre.google/sre-book)
ByteByteGo — System Design Interview Framework (blog.bytebytego.com)
Meta, Google, Amazon — System Design Interview Feedback Patterns (Glassdoor, Blind)
Twitter, YouTube, WhatsApp, Uber, Instagram, Slack — Public Engineering Blogs