System Design Interview Guides

System design interviews ask you to architect a real-world system out loud — "Design a URL shortener," "Design a news feed" — in about 45 minutes. You're not judged on one right answer; you're judged on how you reason about scale, tradeoffs, and failure. These free guides walk through popular questions end to end, and the framework below is the structure every one of them follows.

How to approach any system design interview

Work top-down and narrate your thinking the whole way:

Clarify requirements (~5 min). Pin down what the system must do before designing anything. Separate functional requirements (features) from non-functional ones (scale, latency, availability). Agree on scope with the interviewer — it's fine to declare things out of scope.
Estimate the scale (~5 min). Do quick back-of-the-envelope math: requests per second, read-vs-write ratio, storage growth. These numbers justify every later choice (caching, sharding, which database).
Define the data model and API (~5 min). Name the core entities and the handful of endpoints clients call. This turns a vague problem into something concrete.
Design the high-level architecture (~10-15 min). Draw the boxes — clients, load balancer, services, cache, database, queues — and trace the main read and write paths, calling out the key tradeoffs as you make each choice.
Deep-dive the hard parts (~10–15 min). Pick the 2–3 genuinely difficult pieces (the ones the question is really about) and go deep — this is where you weigh tradeoffs, find bottlenecks, and handle failure modes.

There's no separate "tradeoffs" step on purpose: you surface tradeoffs and bottlenecks throughout, most heavily while designing the architecture and deep-diving. Naming them yourself — before the interviewer asks — is one of the strongest signals you can send.

How to finish the interview

Leave the interviewer with a concise recap. In the last minute, summarize:

The core architecture and the main read/write flows.
The hardest bottleneck and how your design handles it.
The most important tradeoff you chose.
What you would improve next if you had more time.

A simple closing line works well: "To recap, this design optimizes for low-latency reads with a cache-first path, accepts eventual consistency for feed updates, and uses async fan-out to protect write latency. The next thing I would harden is failure handling around the queue and cache."

The building blocks (what each concept means)

Functional requirements — what the system does: the core features and operations users need (e.g. "shorten a URL," "redirect to the original"). Keep the list small and essential.

Non-functional requirements — the qualities the system must have, not its features. These shape the architecture far more than the feature list does. You won't need all of them — identify the top 3–5 that actually matter for this system and make each one concrete (put a number on it). A checklist to draw from:

Scalability — how many users and requests, and any unusual scaling shape: bursty or event-driven spikes (holidays, launches), and the read:write ratio — do reads or writes dominate?
Latency — how fast must it respond, especially for requests that do real work (e.g. low-latency search when designing Yelp)?
Availability — required uptime, and whether a brief outage or a degraded mode is acceptable.
Consistency vs. availability (CAP) — under a network partition, does the system favor consistency (never serve wrong data) or availability (always answer, possibly stale)? Partition tolerance is a given in distributed systems, so this is really a consistency-or-availability choice.
Durability — how bad is data loss? A social feed can tolerate a little; a payments ledger cannot.
Fault tolerance — how gracefully must it survive failures — redundancy, failover, recovery?
Environment constraints — client limits like mobile battery, memory, or bandwidth (e.g. streaming video on a weak connection).
Security & compliance (situational) — data protection, access control, and legal/regulatory rules (PCI, HIPAA, GDPR). Raise these only when the domain demands it, not for every system.

Make each chosen requirement measurable where you can — "p99 < 200 ms," "99.99% uptime," "billions of writes/day" — so your later design choices have a concrete target to satisfy.

Estimations — back-of-the-envelope numbers: QPS (queries per second), the read:write ratio, and data volume (size per item × items × retention = storage). The goal isn't precision — it's the right order of magnitude to justify decisions.

Core entities / data model — the main nouns (User, Post, ShortLink), their fields and relationships, and the choice of store (SQL vs. NoSQL) driven by your access patterns and scale.

API design — the contract between client and server: a few endpoints (or RPCs) with clear inputs and outputs. A small, sharp API keeps the rest of the design honest.

High-level architecture — the component diagram and the data flow: how a request travels through load balancers, services, caches, databases, and queues, for both reads and writes.

Read path / write path — the two most important flows to trace. The read path answers "how does a user fetch or view something?" The write path answers "how does new data enter the system and become visible?" Many systems have very different read and write bottlenecks.

Deep dives — the focused parts where the real difficulty lives: generating unique IDs, fan-out on a news feed, preventing double-booking, distributed rate counting. This is where you show depth.

Consistency — whether every user must see the newest data immediately, or whether a short delay is acceptable. Strong consistency is safer but often slower or harder to scale; eventual consistency is faster and more available but can briefly show stale data.

Failure modes — what happens when a cache, database, queue, region, or third-party service fails. Strong answers do not pretend everything is healthy; they describe retries, fallbacks, replication, and graceful degradation.

Operations — the practical concerns after launch: metrics, logs, alerts, rollout strategy, cost, capacity planning, backfills, and data retention. These matter more as you interview for senior and staff roles.

Tradeoffs and bottlenecks — every design has limits. Where does it break first under load, and what's the next move (cache, shard, replicate, queue)? Strong candidates surface these unprompted.

What to say out loud

System design is partly a communication interview. These sentence starters help you drive the conversation without sounding memorized:

"Let me first clarify the core use cases so I don't over-design the wrong thing."
"I'll make an assumption here, and we can adjust it if you want a different scale."
"The read path and write path have different bottlenecks, so I'll walk through both."
"Given this read-heavy workload, caching becomes a load-bearing part of the design."
"The main consistency question is whether users can tolerate a short delay before updates appear."
"The first thing I expect to break is..."
"If we had more time, I would go deeper on..."

You do not need perfect wording. The point is to keep the interviewer inside your reasoning instead of silently drawing boxes.

What interviewers actually look for

You drive the conversation and manage time across the steps above.
You justify decisions with the requirements and your estimates — not buzzwords.
You go deep on the hard parts instead of staying shallow everywhere.
You name the tradeoffs and know what you'd change as the system grows.

What's expected at your level

Expectations scale with both the question and your target level — nobody is expected to solve a Hard question or nail every deep dive perfectly, especially earlier in their career.

By question difficulty:

Level	What the question involves	What a strong answer shows
Easy	One core feature, modest scale (e.g. a URL shortener).	Clean requirements, a correct working design, rough estimations, one sensible data store. Deep dives stay light.
Medium	More moving parts and higher scale (e.g. a rate limiter).	Solid estimations, a reasoned data model and caching, one or two real deep dives, the main tradeoffs named.
Hard	Genuinely hard sub-problems — fan-out, consistency, concurrency (e.g. a news feed, ticket booking).	Prioritizing the hard parts and going deep on them, handling bottlenecks and failure, and weighing multiple tradeoffs.

By position level:

Role	What's expected
New-grad / Junior	Follow the framework, communicate clearly, and produce a correct, simple design with rough estimations. You're not expected to nail every deep dive or exotic-scale detail. Easy–Medium questions are typical.
Mid-level	A complete working design that handles reasonable scale, at least one solid deep dive, and awareness of the key tradeoffs. Medium questions, sometimes Hard.
Senior	Drive the interview, prioritize and go deep on the hard parts, and surface tradeoffs, bottlenecks, and failure modes proactively. Hard questions are the norm.
Staff+	All of the above, plus crisp prioritization, cross-component systems thinking, and operational concerns (observability, rollout, cost) — and the "why" behind every tradeoff.

Depth where it matters beats shallow coverage everywhere. Pick questions at or slightly above your target level to stretch.

How to practice

If you are new to system design, start with one small, concrete system and repeat it until the framework feels natural. A good path is:

URL shortener — learn requirements, estimations, APIs, caching, and one key-generation deep dive.
Rate limiter — add distributed counters, consistency tradeoffs, and edge cases.
News feed — practice fan-out, ranking, hot users, and read/write path tradeoffs.
Ticket booking — practice concurrency, locking, reservations, and payment reliability.

For senior and staff practice, do not try to cover every box equally. Say which parts are risky and spend your time there. A shallow tour of ten components is weaker than a clear architecture plus two strong deep dives.

Start with these guides

Follow the practice path above with these walkthroughs:

The sidebar lists every available guide, including newer or more specialized questions you can explore after the core path.