Skip to content
ScaleDojo
Join / Sign In
2026 Interview Guide

System Design Interview Cheat Sheet

The frameworks, patterns, and trade-offs that come up in every system design interview distilled into one reference.

Part 01

The 5-Step Interview Framework

Interviewers don't evaluate perfect answers - they evaluate structured thinking. This sequence applies to every question.

1
Clarify Requirements
~3 minutes

Before designing anything, nail down the scope. Assumptions made here drive every decision downstream.

  • Functional: What does the system do? What are the core user actions?
  • Non-functional: Scale (DAU), latency targets, availability SLA, consistency requirements
  • Always ask: read-to-write ratio, data size, expected growth, geographic distribution

Write requirements on the board before drawing a single box - it anchors the rest of the interview.

2
Back-of-Envelope Math
~3 minutes

Rough numbers reveal the architecture. 100 QPS and 100,000 QPS require fundamentally different systems - this is where that distinction becomes concrete.

  • QPS: DAU x avg requests per user / 86,400
  • Storage: users x data per user x retention period
  • Bandwidth: QPS x avg response size

Ballpark estimates, not exact figures. The goal is to identify whether you're in "single server" or "distributed system" territory.

3
High-Level Design
~10 minutes

Draw the big boxes. Don't overthink it. Every system in the world follows roughly the same skeleton:

Client → CDN → Load Balancer → App Servers → Database

Then add the special ingredients based on what the system needs:

  • Need it fast? Add a Cache (Redis)
  • Need to handle spikes? Add a Message Queue (Kafka)
  • Need search? Add Elasticsearch
  • Need to store files/images/video? Add a Blob Store (S3)
4
Deep Dive
~15 minutes

The interviewer will pick a component and ask you to go deeper. Choose 2-3 components and examine the trade-offs, not just the happy path.

  • Don't just say "I'd use a cache" - explain WHAT gets cached, for HOW LONG, and what happens when the cache goes down
  • Don't just say "I'd shard the database" - explain HOW you'd shard (by user ID? by region?) and what breaks when you do
  • Always mention: What could go wrong? How would you monitor it?
5
Wrap Up & Scale
~2 minutes

Don't just stop when the diagram is drawn. Close with:

  • Where are the bottlenecks? What breaks first at 10x scale?
  • How would you monitor this? (metrics, alerts, dashboards)
  • What would you build in v2? (shows you think beyond the interview)

Numbers Every Engineer Should Have Memorized

1 day = 86,400 seconds (just say ~100K)
1 month = ~2.5 million seconds
1 char = 1 byte
1 image = ~300 KB
1 video (1 min) = ~50 MB
1 tweet-sized text = ~280 bytes
SSD read = 0.1 ms (super fast)
Network round trip = ~150 ms
1M requests/day = ~12 QPS
1B requests/day = ~12,000 QPS
Redis read = 0.1 ms
DB query = 1-10 ms (indexed)
Part 02

15 Most Common System Design Questions

These questions appear across FAANG, mid-stage companies, and startups. Each maps to a repeatable architecture pattern - learn the pattern, and variations become straightforward.

#QuestionCore PatternThe Trap Most People Fall IntoDifficultyPractice
01URL Shortener (TinyURL)Hashing + Key-Value StoreForgetting collision handling with Base62. What happens when two URLs hash to the same key?EasyLevel 3 →
02Rate LimiterToken Bucket / Sliding WindowOnly designing for a single server. In real life, you need distributed counting (Redis + Lua scripts)EasyLevel 4 →
03Notification SystemQueue + Priority RoutingTreating all notifications the same. SMS, push, email have completely different delivery guarantees and costsMediumLevel 5 →
04Key-Value Store (Redis)Consistent Hashing + ReplicationNot discussing what happens during a network partition. How do you handle split-brain scenarios?MediumLevel 6 →
05Web Crawler (Google)BFS Queue + Workers + DedupIgnoring politeness (don't DDoS websites!) and URL deduplication at scaleMediumLevel 8 →
06Twitter / News FeedFanout on Write vs ReadUsing the same strategy for celebrities (10M followers) and regular users. Hybrid fanout is the answerHardLevel 10 →
07WhatsApp / Chat SystemWebSocket + Message QueueNot handling offline users. Where do messages go when someone's phone is off? You need a persistent queueHardLevel 11 →
08Search AutocompleteTrie + Ranking + CachingBuilding a trie that updates in real-time. In reality, you rebuild it periodically and serve from cacheMediumLevel 12 →
09YouTube / Video PlatformStreaming + CDN + TranscodingForgetting the transcoding pipeline. A single video needs 20+ formats (different resolutions, codecs, devices)HardLevel 13 →
10Google Drive / DropboxChunked Upload + Sync EngineNot addressing conflict resolution. What if two people edit the same file at the same time?HardLevel 14 →
11Uber / Ride SharingGeospatial Index + MatchingUsing simple lat/lng queries. You need geohashing or quadtrees for efficient nearby-driver lookupsHardLevel 18 →
12Instagram / Photo SharingBlob Storage + CDN + FeedStoring images in the database. Images go in S3/blob storage, only metadata goes in the DBMediumLevel 16 →
13Payment System (Stripe)Idempotency + Saga PatternNot making payments idempotent. If a request retries, you could charge someone twice. Idempotency keys are mandatoryHardLevel 21 →
14Monitoring System (Datadog)Time-Series DB + AggregationTrying to store raw metrics forever. You need downsampling: keep 1-second data for 1 day, 1-minute data for 30 days, 1-hour data for 1 yearHardLevel 19 →
15AI Chatbot (RAG System)Vector DB + LLM + EmbeddingsSending entire documents to the LLM. You need chunking + embedding + similarity search to find relevant pieces firstHardBlog →

Want to actually build these systems, not just read about them? ScaleDojo has 70+ interactive levels where you drag-and-drop components, connect them, and get AI-powered feedback on your architecture.

Start Practicing Free →

Part 03

The Database Decision Tree

The #1 question interviewers ask to test your judgment: "Why did you pick that database?" Here's how to answer it every time.

"I need transactions that never lose money"

→ PostgreSQL / MySQL

When you're dealing with money, orders, or anything where "almost correct" isn't good enough, you need ACID transactions. Think of it like a bank vault - every operation either fully completes or fully rolls back. No in-between.

"I need to scale to millions of writes per second"

→ DynamoDB / Cassandra

When you're writing more than reading (like IoT sensors or activity logs), these databases spread data across hundreds of machines automatically. They sacrifice some consistency for insane write speed. Like having 100 cash registers instead of 1.

"I need sub-millisecond lookups"

→ Redis / Memcached

These keep everything in memory (RAM), not on disk. It's the difference between grabbing a book from your desk vs walking to the library. 1000x faster. Use for sessions, leaderboards, rate limiting, and caching hot data.

"I need to search through millions of documents"

→ Elasticsearch

Regular databases search by exact matches. Elasticsearch searches by MEANING. It builds an inverted index (like the index at the back of a textbook) so it can find "running shoes" even if the document says "sneakers for jogging."

"I need to store time-stamped metrics"

→ InfluxDB / TimescaleDB

Regular databases aren't built for "give me the average CPU usage every 5 minutes for the last 3 months." Time-series databases optimize for exactly this - they compress sequential timestamps and make aggregation queries lightning fast.

"I need to find connections between things"

→ Neo4j / Amazon Neptune

When your data is about relationships (social networks, recommendation engines, fraud detection), graph databases let you ask "who are the friends of friends of this user?" in milliseconds. In SQL, that same query would take minutes with multiple JOINs.

"I need to find similar items by meaning"

→ Pinecone / pgvector / Weaviate

Vector databases store things as numbers that represent MEANING. So "happy" and "joyful" are stored close together. This powers AI search, recommendation systems, and RAG chatbots.

"I need flexible schema that changes often"

→ MongoDB / CouchDB

When you're building fast and your data shape keeps changing (startups, prototypes), document databases let you store anything without defining the structure upfront. Like a filing cabinet where each folder can have different contents.

Part 04

Caching Strategies

Caching eliminates redundant database calls and is often the highest-leverage performance improvement available. The trade-off is always between freshness and speed.

Cache-Aside (Lazy Loading)
The app checks the cache first. If the data is there (cache hit), great, return it. If not (cache miss), go to the database, get the data, put it in the cache, then return it. Like checking your pocket for your keys before going back to the house.
Best for: Read-heavy workloads. This is the most common strategy - use it by default.
Write-Through
Every time you write data, you write it to BOTH the cache and the database at the same time. The cache is never stale because it always matches the DB. But writes are slower because you're writing twice.
Best for: Data that's read immediately after writing (like a user profile update).
Write-Back (Write-Behind)
Write to the cache only. The cache batches up changes and writes them to the database later, in the background. Super fast writes, but if the cache crashes before flushing, you lose data. It's a speed-vs-safety trade-off.
Best for: Write-heavy workloads where occasional data loss is acceptable (like view counters).
Cache Invalidation
The hardest problem in caching. When the underlying data changes, how do you make sure the cache doesn't serve the old version? You can set a TTL (time to live), or actively delete the cache entry when data changes.
Rule of thumb: TTL of 5 min for feeds, 1 hour for profiles, 24 hours for static content.

"There are only two hard things in Computer Science: cache invalidation and naming things." - Phil Karlton

Discussing cache invalidation proactively - not just the cache-hit path - signals engineering depth to interviewers.

Part 05

The Scaling Ladder

Systems don't start at Netflix scale. They grow. Here's what you add at each stage, and WHY. This is gold for "how would you scale this?" follow-ups.

< 1K

Single Server

Web server, application logic, and database all on one machine. Suitable for early-stage products with low traffic. Resist the urge to add complexity before you need it.

< 100K

Separate DB + Read Replicas

Separate the database onto its own server. Add read replicas to offload query traffic from the primary. Place a load balancer in front of multiple application servers. Most startups operate at this tier for years.

< 1M

Cache + CDN + Horizontal Scale

Introduce Redis to cache hot data (sessions, feeds, popular queries). Serve static assets from a CDN. Scale application servers horizontally behind the load balancer. Database reads are now mostly served from cache.

< 10M

Shard DB + Message Queues + Microservices

Your single database can't handle 10M users. Time to shard (split data across multiple databases by user ID or region). Add Kafka for async processing. Break your monolith into microservices so teams can work independently. This is where things get serious.

< 100M

Multi-Region + Edge Computing

Deploy across multiple regions (US, Europe, Asia). Route traffic to the nearest data center. Implement CRDTs or conflict resolution for cross-region data consistency. This is the architecture major streaming and social platforms run.

> 100M

Planet Scale (Custom Everything)

Off-the-shelf solutions hit their limits. Google built Spanner, Amazon built DynamoDB, Meta built TAO - custom infrastructure designed around one company's specific access patterns and consistency requirements.

Part 06

8 Key Trade-Offs to Know

System design interviews are evaluated on trade-off reasoning, not on arriving at a single "correct" architecture. These are the comparisons that come up repeatedly.

SQLVSNoSQL
SQL gives you structure, relationships, and ACID transactions. NoSQL gives you flexibility, speed, and easy horizontal scaling. Think of SQL like a spreadsheet with strict columns, and NoSQL like a folder of sticky notes.
Pick SQL for financial data, user accounts. Pick NoSQL for logs, real-time analytics, rapidly changing schemas.
Push (Fanout on Write)VSPull (Fanout on Read)
Push: when you post something, it gets immediately written to all your followers' feeds. Pull: followers' feeds are computed on-the-fly when they open the app. Push is fast to read but expensive to write. Pull is cheap to write but slow to read.
Twitter uses hybrid: push for regular users, pull for celebrities (Elon has 180M followers - you can't write to 180M feeds instantly).
Strong ConsistencyVSEventual Consistency
Strong: everyone sees the same data at the same time. Eventual: different users might briefly see different versions, but they'll all catch up.
Strong for banking, inventory counts, seat booking. Eventual for likes, follower counts, activity feeds.
MonolithVSMicroservices
Monolith: one codebase, one deployment, one team. Simple but hard to scale. Microservices: many small services, each owned by a team. Flexible but complex (you now need service discovery, API gateways, distributed tracing).
Start with a monolith. Split into microservices ONLY when you have 50+ engineers or specific scaling bottlenecks. Don't microservice a startup.
WebSocketVSLong Polling
WebSocket keeps a permanent open connection between client and server. It's like a phone call - always connected. Long polling is like texting "any updates?" every 5 seconds. WebSocket is more efficient but harder to scale (you need sticky sessions).
WebSocket for chat, gaming, live collaboration. Long polling or SSE for notifications, dashboards, less frequent updates.
Sync ProcessingVSAsync Processing
Sync: the user waits until the task is done. Async: the user gets a "we'll notify you" response immediately, and the work happens in the background.
Sync for instant feedback (login, search). Async for expensive operations (video processing, email sending, report generation).
NormalizeVSDenormalize
Normalized: store data once, join tables when needed (saves storage, always consistent). Denormalized: duplicate data across tables to avoid expensive joins (faster reads, but you need to update multiple places when data changes).
Normalize for write-heavy systems. Denormalize for read-heavy systems (feeds, dashboards, search results).
AvailabilityVSConsistency (CAP)
The CAP theorem says during a network failure, you must choose: keep responding (availability) but maybe serve old data, OR stop responding until data is synced (consistency). You can't have both during a partition.
Banks choose consistency (better to show "system unavailable" than a wrong balance). Social media chooses availability (showing a slightly outdated like count is fine).
Part 07

12 Core Building Blocks

These components appear in almost every system design answer. Know what each one is, when to reach for it, and what you're trading away when you add it.

01
Load Balancer
Distributes incoming requests across a pool of servers. Health checks route traffic away from unhealthy instances. L4 balancers operate at the transport layer; L7 balancers route based on HTTP headers, cookies, and paths.
Round robin, least connections, L4 vs L7, health checks, sticky sessions
02
CDN
Distributes static assets (images, JS, video) across edge servers worldwide so requests are served from the nearest point-of-presence rather than the origin. Dramatically reduces latency for geographically dispersed users.
Edge servers, cache hit ratio, origin server, TTL, geo-routing
03
Message Queue
Decouples producers from consumers. The producer writes a message and moves on; the consumer processes it independently and at its own pace. Absorbs traffic spikes, enables retry logic, and prevents cascading failures.
Producer/consumer, topic/partition, dead letter queue, at-least-once delivery
04
API Gateway
Single entry point in front of backend services. Handles authentication, rate limiting, request routing, and protocol translation in one place rather than duplicating that logic across every service.
Auth, rate limiting, request routing, protocol translation, API versioning
05
Consistent Hashing
Standard modulo hashing reshuffles nearly all keys when nodes are added or removed. Consistent hashing limits redistribution to 1/N of keys, making it practical for distributed caches and storage clusters.
Hash ring, virtual nodes, rebalancing, data locality
06
DNS
Translates human-readable hostnames to IP addresses. TTL controls how long resolvers cache records. Geo-DNS routes users to regional endpoints by resolving different IPs based on the requester's location.
DNS resolution, TTL, A/AAAA records, CNAME, geo-DNS for load distribution
07
Database Sharding
Partitions data horizontally across multiple database instances by shard key. Eliminates the single-write-leader bottleneck at scale. Introduces cross-shard query complexity and makes rebalancing operationally difficult.
Shard key, range vs hash sharding, cross-shard queries, rebalancing
08
Database Replication
Maintains copies of data on multiple nodes. The primary handles writes; replicas serve reads. Automatic failover promotes a replica if the primary fails. Replication lag is the key trade-off with eventual consistency.
Leader-follower, multi-leader, replication lag, failover, quorum
09
Event Sourcing
Stores state as an immutable, append-only log of events rather than the current value. Any past state can be reconstructed by replaying the log. Pairs naturally with CQRS and audit-trail requirements.
Event log, append-only, replay, CQRS, materializing views
10
Rate Limiting
Enforces a ceiling on requests per client per time window. Protects backend services from traffic spikes, abusive clients, and DDoS. Distributed rate limiting (Redis + Lua scripts) is necessary in multi-instance deployments.
Token bucket, sliding window, fixed window, distributed rate limiting with Redis
11
Bloom Filter
Probabilistic data structure that answers "definitely not in set" with certainty and "possibly in set" with configurable false-positive rate. Used to avoid expensive lookups (e.g., "has this URL been crawled?") with minimal memory.
Probabilistic, false positives (no false negatives), space-efficient, dedup
12
Circuit Breaker
Monitors failure rate on calls to a downstream service. After a threshold is crossed, it "opens" and stops forwarding requests for a cooldown period, preventing cascading failures when a dependency degrades.
Open/closed/half-open states, fallback, resilience, timeout handling
Part 08

7 Common Mistakes and How to Fix Them

Most interview rejections aren't caused by missing knowledge - they're caused by how that knowledge is communicated.

What People Say
"I'd use Kafka here."
->
What Gets You Hired
"We need async processing here because users shouldn't wait for email notifications to be sent. A message queue like Kafka lets us decouple the notification service. If it goes down, messages are buffered, not lost."
What People Say
"I'd use a NoSQL database."
->
What Gets You Hired
"Our data model is flexible - each user's profile can have different fields. A document store like MongoDB lets us iterate fast without migrations. The trade-off is we lose JOIN support, but our access patterns are single-document reads anyway."
What People Say
"We can just add more servers."
->
What Gets You Hired
"Horizontal scaling works for stateless app servers. But our database is the bottleneck. We should first add a caching layer to reduce DB load, then implement read replicas for read-heavy queries, and only shard if we outgrow a single write leader."
What People Say
Jumping straight into the solution without asking questions.
->
What Gets You Hired
"Before I design, let me clarify: are we optimizing for read latency or write throughput? What's our expected DAU? Do we need real-time or is eventual consistency OK? Are we targeting a single region or global deployment?"
What People Say
"This system will be available 100% of the time."
->
What Gets You Hired
"We can target 99.99% availability (about 52 minutes of downtime per year) with active-passive failover and health checks. True 100% is practically impossible - even Google goes down. The cost of going from 99.99% to 99.999% is 10x."
What People Say
"I'd store everything in one database."
->
What Gets You Hired
"Different data has different access patterns. User metadata in PostgreSQL (structured, relational). Session data in Redis (fast lookups, auto-expiry). Media files in S3 (cheap, durable). Search index in Elasticsearch. This is polyglot persistence."
What People Say
Drawing a diagram and staying silent.
->
What Gets You Hired
Narrate your thinking out loud: "I'm putting a load balancer here because if any app server crashes, traffic automatically routes to healthy ones. I chose an L7 load balancer specifically because we need to route based on URL paths."
Part 09

Learning Roadmap

22 topics organized by dependency. Each tier assumes the previous one. Studying in this order avoids the common mistake of learning distributed systems concepts before understanding database fundamentals.

Foundation (Start Here)
  • Networking Basics (TCP, HTTP, DNS)
  • Databases & Storage (SQL, NoSQL, ACID)
  • API Design (REST, HTTP methods)
  • Caching Strategies (Redis, CDN)
  • Load Balancing (L4/L7, algorithms)
  • Auth & Security (JWT, OAuth, RBAC)
  • Back-of-Envelope Estimation
Intermediate (Level Up)
  • Message Queues (Kafka, RabbitMQ)
  • Database Scaling (Sharding, Replication)
  • Advanced API (gRPC, GraphQL, Webhooks)
  • Microservices Architecture
  • Consistency Models (CAP, Quorum)
  • Real-Time Systems (WebSocket)
  • Design Patterns (CQRS, Saga)
  • Observability (Metrics, Logs, Traces)
Advanced (Senior+)
  • Search & Feed Systems
  • Storage at Scale (S3, Data Lakes)
  • FinTech Systems (Payments, Ledgers)
  • Planet-Scale Design (Multi-Region)
  • Architect's Mindset
  • AI/ML System Design (RAG, LLM)
  • Chaos Engineering

This exact roadmap is available as an interactive, clickable map at /roadmap - each topic links to a detailed blog post with diagrams and examples. Completely free. No signup needed.

Part 10

Availability Reference

Translate SLA percentages into real downtime figures. Each additional nine of availability costs roughly 10x more in engineering effort and infrastructure.

AvailabilityDowntime / YearReal-World Example
99% (two 9s)3.65 daysInternal tools, dev environments
99.9% (three 9s)8.77 hoursSaaS apps, content sites
99.99% (four 9s)52.6 minutesE-commerce, banking, health
99.999% (five 9s)5.26 minutesAWS, Google Cloud, stock exchanges

Each extra 9 costs roughly 10x more money and engineering effort. For most systems, four 9s is the sweet spot.

ScaleDojo Logo
Initializing ScaleDojo