Use this checklist on every system design question. The shape is the same whether the prompt is a URL shortener, a rate limiter, or a full news feed.

Step 1: Clarify requirements and scope

Split requirements into functional (what must the system do, i.e. the core use cases) and non-functional (scale, latency, availability targets). Ask about read/write ratio and rough traffic numbers before drawing a single box. Confirm what is explicitly out of scope; interviewers expect you to negotiate scope, not design everything.

Step 2: Estimate scale

Back-of-envelope QPS, storage, and bandwidth from the numbers in Step 1 (daily active users, requests per user, average payload size). You do not need precision; round to the nearest order of magnitude and state your assumptions out loud. These numbers drive later decisions, since a single Postgres instance is fine at 100 QPS but not at 100k.

Step 3: Define the core entities and API

List the nouns the system needs to model (for a URL shortener: ShortURL, User, ClickEvent) and sketch the API surface, the endpoints or function signatures a client would call. This forces you to pin down the contract before the architecture.

Step 4: High-level design

Draw boxes and arrows: client, API layer, application servers, data stores, cache, queue, whatever the problem needs. Walk through one request end to end (write path, then read path) before adding anything else. Keep this version simple; you will deepen it in the next step.

Step 5: Deep dive on the bottleneck

Pick the one or two components where the interesting trade-offs live, usually the database choice, a caching layer, or a hot-path service, and go deep: SQL vs. NoSQL and why, cache invalidation strategy, how you shard or partition, how you keep a counter or ranking consistent under concurrent writes. This is where most of the interview signal comes from; do not spend all your time on Step 4's boxes.

Step 6: Scale, fail, and trade off

Address what breaks first as load grows (single point of failure, hot shard, cache stampede) and how you would fix it: replication, load balancing, horizontal partitioning, rate limiting at the edge. State the trade-off explicitly (consistency vs. availability, cost vs. latency); naming the trade-off matters more than picking a "correct" side.

Step 7: Wrap up

Summarize the design in two sentences, note what you would monitor in production (error rate, p99 latency, queue depth), and flag anything you would revisit with more time. A clean close signals seniority as much as the design itself.

What Are the Most Common System Design Interview Questions?

Most prompts are a variation on a handful of underlying problems. Run each one through the 7-step framework above instead of memorizing a fixed architecture; the interesting part is almost always the deep dive in Step 5, not the boxes in Step 4.

Social and feed systems

• Design a news feed (Facebook, LinkedIn) — the hard part is fan-out on write vs. fan-out on read for users with millions of followers.
• Design Instagram or a photo-sharing app — object storage and CDN placement for media, plus a feed ranking service on top.
• Design a notification system — fan-out to push, email, and SMS with per-channel retry and de-duplication.

Messaging and real-time

• Design WhatsApp or a chat system — message ordering, delivery receipts, and connection state at scale (long-lived WebSocket or persistent connections per user).
• Design a live comments or reaction feed — high write volume against a single hot key (the post), and how you shard or batch around it.
• Design a collaborative document editor (Google Docs) — operational transforms or CRDTs for concurrent edits, not a database schema question.

Infra and platform

• Design a rate limiter — token bucket vs. sliding window, and where the limiter sits (edge, gateway, or per-service). Worked through step by step.
• Design a URL shortener — the canonical warm-up question: ID generation strategy, redirect latency, and read-heavy caching. Worked through step by step.
• Design a web crawler — politeness/rate limits per domain, dedup at scale, and a distributed frontier queue.
• Design a distributed cache or key-value store — consistent hashing, replication, and how you handle a hot key.
• Design a job scheduler or distributed task queue — exactly-once vs. at-least-once delivery, and retry/backoff design.
• Design an ad click aggregator or metrics pipeline — high-throughput ingestion with a streaming aggregation layer (Kafka-style), not a single database write path.

Storage and retrieval

• Design a search autocomplete or type-ahead service — a trie or prefix index kept in memory, refreshed from a slower batch job.
• Design a distributed file storage system (Dropbox, Google Drive) — chunking, deduplication, and sync conflict resolution.
• Design a ticketing or seat-reservation system (Ticketmaster) — preventing double-booking under concurrent writes, usually with optimistic locking or a short-lived hold.

Commerce and marketplace

• Design a ride-sharing dispatch system (Uber, Lyft) — geospatial indexing (geohashing or a quadtree) to match riders and drivers nearby in real time.
• Design a payment or checkout system — idempotency keys so a retried request never double-charges, plus a reconciliation path for failures.

None of these need a memorized textbook diagram. The prompt is a stand-in for testing whether you can scope it (Step 1), size it (Step 2), and go deep on the one or two components where the real trade-off lives (Step 5) — the same reasoning the parking lot exercises on a single-process design instead of a distributed one.

FAQ

How long should a system design interview answer take?

Most onsite loops give you 45 minutes. Roughly: 5 min requirements, 5 min estimation, 10 min high-level design, 15 min deep dive, 10 min wrap-up and trade-offs. The exact split moves depending on the interviewer's questions, but deep dive should always be your longest block. A shallow deep dive is the most common reason a design interview underperforms.

Do I need real production experience to answer these well?

It helps but is not required. What interviewers actually grade is structured reasoning: can you break scope into requirements, defend a design decision with a trade-off, and reason about what breaks at scale. Working through curated questions with the algorithms and placement decisions spelled out builds that reasoning even without prior infrastructure experience.

What's the difference between a system design interview and an OOD interview?

System design is about distributed systems at scale: multiple servers, databases, caches, network boundaries. OOD interviews are about class structure and responsibilities in a single process, like a parking lot or an elevator system. Some prompts (a rate limiter, for example) get asked both ways: as a distributed-systems problem with Redis and sharding, or as a single-class design problem. Confirm which one you're being asked before you start.

Do I need to memorize specific architectures?

No. Memorizing "the Twitter architecture" fails the moment the interviewer changes one requirement. Memorize the framework above instead; it generates a reasonable architecture for almost any prompt because the estimation and trade-off steps adapt to whatever numbers and constraints you're given.

Related reading

• A 45-minute system design framework — the condensed version of this framework.
• Design a rate limiter — algorithm choices (token bucket, sliding window) and distributed placement, worked through step by step.
• How to approach OOD interviews — the class-design counterpart to this framework.