System Design Interview Framework & Cheat Sheet

April 2026 · 22 min read

This is it — the final post in our 70-part High Level Design series. Over the course of this journey we have covered foundations, building blocks, data storage engines, distributed systems theory, architecture patterns, and dozens of real-world case studies. This post ties everything together into one actionable reference you can use the night before — or morning of — your system design interview.

1 · The 4-Step Framework

Every system design interview — from FAANG to startups — follows roughly the same shape. The biggest differentiator between candidates who pass and those who don't is structure. Having a repeatable framework keeps you on track, ensures you cover all the bases, and signals to the interviewer that you think methodically about complex problems.

Step 1: Understand Requirements — In Depth

The first five minutes of a system design interview determine its trajectory. Candidates who jump straight to drawing boxes fail because they solve the wrong problem. Here is a structured approach to requirement gathering:

Functional requirements define what the system does — the user-visible features. Ask:

• Who are the users? (consumers, businesses, internal teams)
• What are the core use cases? (e.g., "Users can post a tweet and see a feed of tweets")
• Any features explicitly out of scope? (e.g., "Don't worry about DMs for now")

Non-functional requirements define how well the system performs — the quality attributes:

Step 2: Back-of-Envelope Estimation — In Depth

Estimations ground your design in reality. You don't need exact numbers — you need the right order of magnitude so you can justify architectural choices (e.g., "We need sharding because a single MySQL can't handle 50K writes/sec").

Template for estimation:

// Given: 500M DAU, each user posts 2 tweets/day and reads 100 tweets/day

Write QPS  = 500M × 2 / 86400 ≈ 12,000 writes/sec
Read QPS   = 500M × 100 / 86400 ≈ 580,000 reads/sec
Read:Write = ~50:1 (read-heavy → optimize for reads)

Storage (5 years):
  Each tweet ≈ 250 bytes (text) + 500 bytes (metadata) = 750 bytes
  500M × 2 tweets/day × 365 × 5 years × 750 B ≈ 1.37 PB

Bandwidth:
  Write: 12,000 × 750 B ≈ 9 MB/s ingress
  Read:  580,000 × 750 B ≈ 435 MB/s egress

Cache (80/20 rule — cache 20% of daily reads):
  Daily reads = 500M × 100 × 750 B = 37.5 TB/day
  Cache 20% = ~7.5 TB → need a distributed cache cluster (Redis)

Step 3: High-Level Design — In Depth

This is the core of the interview. Draw a clean architecture diagram with these standard building blocks:

1. Clients — mobile, web, API consumers
2. Load Balancer — distributes traffic across application servers
3. Application Servers — stateless service tier (horizontally scalable)
4. Cache Layer — Redis/Memcached for hot data
5. Database — primary data store (SQL or NoSQL)
6. Message Queue — async processing (Kafka, RabbitMQ)
7. CDN — static assets, media delivery
8. Object Storage — S3 for blobs, images, videos

Define API contracts clearly — even brief REST endpoints show you think about interfaces:

POST /api/v1/tweets
  Body: { "text": "Hello world", "media_ids": ["abc123"] }
  Response: 201 { "tweet_id": "xyz789", "created_at": "..." }

GET  /api/v1/feed?user_id=123&cursor=abc&limit=20
  Response: 200 { "tweets": [...], "next_cursor": "def" }

Step 4: Deep Dive — In Depth

This is where senior candidates separate themselves. Pick the most interesting or challenging components and go deep:

• Database choice & schema design — Why SQL over NoSQL (or vice versa)? How will you shard? What indexes?
• Caching strategy — Write-through vs. write-behind vs. cache-aside? Eviction policy? Cache invalidation?
• Consistency model — Where is eventual consistency acceptable? Where do you need strong consistency?
• Failure handling — What if a service goes down? Circuit breakers? Retries with exponential backoff? Saga pattern for distributed transactions?
• Scaling bottlenecks — Where will the system hit limits first? How do you scale past them?

2 · Estimation Cheat Sheet

Powers of 2

Memorize these — they are the building blocks of every back-of-envelope calculation:

Latency Numbers Every Engineer Should Know

These numbers, originally compiled by Jeff Dean, help you reason about where time is spent in a system:

Common Conversions

3 · Component Cheat Sheet

One of the most common questions in a design interview is "Why did you choose this component?" Here is a quick reference for when to use each building block:

4 · Pattern-to-Problem Mapping

This table maps common system design problems to the key patterns and concepts they test. Use it to identify which patterns are relevant when you hear a problem statement:

5 · Common Mistakes

After conducting hundreds of mock interviews, these are the most frequent mistakes candidates make — and how to avoid each one:

• ❌ Not asking clarifying questions. Jumping to design immediately signals you don't think critically. Always spend the first 3–5 minutes understanding the problem. Even if you think you know what "Design Twitter" means, ask: "Should we focus on the feed, the posting, search, or DMs?"
• ❌ Jumping to the solution. Starting with "Let's use Kafka and Redis" before defining what the system needs to do. Always requirements first, then design. The interviewer wants to see your thought process, not just the answer.
• ❌ Over-engineering. Adding microservices, CQRS, event sourcing, and a service mesh for a system that handles 100 requests/day. Match the complexity of your architecture to the scale of the problem. A monolith is a valid answer for many scales.
• ❌ Ignoring non-functional requirements. Designing a beautiful architecture that doesn't meet the latency, availability, or consistency requirements. Non-functionals drive the architecture — not the other way around.
• ❌ Not discussing trade-offs. Every decision has pros and cons. Saying "I'll use NoSQL" without explaining why (e.g., "because we need flexible schema and high write throughput at the cost of weaker consistency") is a missed opportunity to show depth.
• ❌ Single point of failure. Every component in your design should be redundant. If your load balancer, database, or cache has a single instance, call it out and explain how you'd add redundancy.
• ❌ Not mentioning monitoring. A production system without monitoring, alerting, and logging is incomplete. Even a one-sentence mention ("We'd add Prometheus metrics and distributed tracing with Jaeger") shows production awareness.

6 · Red Flags Interviewers Watch For

Beyond common mistakes, these are the behaviors that actively lower your interview score. Interviewers are trained to spot them:

• 🚩 No requirements gathering at all. Immediately drawing boxes without a single question. This suggests you memorized a solution rather than thinking from first principles. Interviewers often intentionally leave the problem vague to test this.
• 🚩 Monolithic thinking. Putting everything in one giant server. Even if you start with a monolith (which is fine!), you should articulate how you'd scale it — which parts would you extract, and at what trigger points.
• 🚩 Ignoring failure modes. A design that only works when everything is up. The interviewer will ask "What happens when X goes down?" and you should have thought about it. Mention circuit breakers, retries, fallbacks, and replication.
• 🚩 Magic numbers without estimation. Saying "We need 100 servers" without showing the math. Even a rough calculation shows rigor: "At 12K writes/sec and ~1K writes/sec per server, we need ~12 servers plus buffer."
• 🚩 No trade-off discussion. Presenting a design as though every choice is obvious. Real engineering is about trade-offs. The interviewer wants to hear: "I chose X over Y because…" with clear reasoning.
• 🚩 Buzzword dropping. Saying "blockchain," "machine learning," or "serverless" without understanding how they apply. It's better to use fewer technologies well than to name-drop technologies you can't defend.
• 🚩 Not adapting to feedback. If the interviewer hints that a component won't scale or suggests a different approach, don't stubbornly stick to your original design. Adaptability is a key signal.
• 🚩 No API or data model discussion. Talking only in abstract boxes without defining what data flows between them. Even simple REST endpoints and table schemas show you think concretely about interfaces.

7 · Topic Difficulty Tiers

Not all system design problems are equal. Here's how they break down by difficulty, so you can prioritize your study time and know what to expect at different interview levels:

Easy — Warm-up & Phone Screens

These problems have well-known solutions and test whether you can articulate basic system design concepts clearly. Expected in phone screens and junior/mid-level interviews.

Medium — Standard On-site

These are the most common on-site interview questions. They require combining multiple building blocks and making meaningful trade-off decisions.

Hard — Senior & Staff-Level

These require deep understanding of distributed systems, data-intensive architectures, and nuanced trade-offs. Expected in senior and staff-level loops.

Expert — Principal & Architect

These problems have no single "right" answer and require deep domain knowledge. Expected in principal/architect interviews or as follow-up deep dives.

8 · 8-Week Study Plan

This plan covers the entire 70-post series in a structured 8-week roadmap. Each week builds on the previous one. Aim for 1–2 hours of focused study per day.

Animation 1: Interactive Framework Walkthrough

Animation 2: Interactive Difficulty Matrix