Top 25 System Design Interview Questions With Detailed Walkthroughs

Here's a secret that takes the fear out of system design interviews: the question list is finite.

Google, Meta, Amazon, Netflix, Uber, Stripe, and Microsoft all draw from the same pool of 25-30 classic problems. They ask "design a URL shortener" not because they need a new TinyURL, but because the problem exercises sharding, caching, consistent hashing, and read-heavy workload optimization in a 45-minute window. They ask "design WhatsApp" because it exercises WebSockets, delivery guarantees, and fan-out. They ask "design Uber" because it exercises geospatial indexing and real-time matching.

The problems recycle because they test fundamentals, not trivia.

Master these 25 questions and you've covered 90% of what you'll actually face. But here's the thing: memorizing answers doesn't work. System design interviews are open-ended conversations. The interviewer isn't checking your architecture against a rubric. They're evaluating whether you can reason about trade-offs under ambiguity, communicate clearly while thinking on your feet, and make decisions that hold up when they push back.

That means you need two things: a framework for approaching any question (so you never stare at a blank whiteboard), plus enough practice on specific problems that the patterns become second nature.

This guide gives you both. The first section is the framework — a 9-step methodology you can apply to any system design question you'll ever see. The rest is the 25 most-asked questions, organized by category, each with a summary of the key design decisions and a link to the full walkthrough where one exists.

Let's start with the framework.

The 9-step framework for any system design question

Every system design question, from "design a URL shortener" to "design Netflix," can be answered with the same structure. Interviewers are trained to listen for these steps, and hitting them in order is the fastest way to signal that you know what you're doing. Skip a step and the interviewer will prompt you back to it. Hit them all, and you'll fill the 45 minutes naturally without running out of things to say.

Step 1: Clarify requirements (2-3 minutes). Ask what features are in scope and what's out of scope. "Should the chat app support group messaging? Voice calls? Read receipts? End-to-end encryption?" This prevents you from designing the wrong thing. Interviewers want to see you narrow scope before you draw boxes. For the deep dive, see how to gather and prioritize requirements.

Step 2: Estimate capacity (3-5 minutes). Do the math out loud. How many users? How many requests per second? How much storage per year? How much bandwidth? This grounds your design in reality. A system serving 1,000 QPS is radically different from one serving 1,000,000 QPS, and that difference changes every decision downstream. See back-of-the-envelope estimation for the technique and the numbers you should memorize.

Step 3: Define the API (2-3 minutes). What endpoints does your system expose? Name 3-5 core API calls with their inputs and outputs. This forces you to think about the contract between clients and servers before you design the internals. It also surfaces edge cases early: "does the create-post endpoint return the post ID synchronously, or is post creation asynchronous?" See mastering the API interview for the principles.

Step 4: Design the data model (3-5 minutes). What tables or collections do you need? What are the primary keys, partition keys, and indexes? What's the sharding strategy? The data model often determines the entire system architecture. If you partition messages by conversation_id, cross-conversation queries become expensive. If you partition by user_id, single-conversation queries require a scatter-gather. Naming this trade-off explicitly is a senior signal. See database sharding guide and database indexing explained.

Step 5: Sketch the high-level architecture (5 minutes). Draw the boxes: client, load balancer, API servers, database, cache, message queue, CDN. Show how data flows through them for the primary use case. Don't go deep yet — just establish the landscape. Most systems at FAANG scale share the same skeleton: stateless API servers behind a load balancer, a sharded database layer, a cache layer (usually Redis), and an async processing layer (usually Kafka). The differences are in the details you'll unpack next.

Step 6: Deep dive on 2-3 components (10-15 minutes). The interviewer will point to one box and say "tell me more." This is where your specific knowledge shines. Common deep-dive topics: caching strategies, load balancing algorithms, message broker selection, and consistency models. The key: don't wait for the interviewer to pick. Proactively say "the most interesting trade-off in this design is X, let me dive into that."

Step 7: Discuss trade-offs explicitly. This is the step that separates "pass" from "strong hire." For every decision — SQL vs NoSQL, push vs pull, strong vs eventual consistency — name what you're gaining and what you're giving up. Never say "I'd use Cassandra." Say "I'd use Cassandra because we need high write throughput and can tolerate eventual consistency, but the trade-off is weaker support for ad-hoc queries." See CAP theorem vs PACELC for the framework.

Step 8: Address scalability bottlenecks (3-5 minutes). Walk through what happens when traffic 10x's. Which component breaks first? How do you fix it? The bottleneck is almost always the database (add read replicas, shard, add a cache in front) or the write path (add a message queue to absorb bursts). See scalability in system design and high availability strategies.

Step 9: Handle follow-up questions (rest of the time). The interviewer will probe failure modes, edge cases, and alternative approaches. The best preparation: for every box in your diagram, pre-think "what happens if this component fails?" The follow-ups are where practice on specific problems pays off.

That's the framework. Print it, memorize the step numbers, and use it on every problem. Now let's apply it to the 25 questions.

Social media and content platforms

These questions test fan-out, ranking algorithms, user-generated content, and read-heavy systems at massive scale. At least one will appear in almost every FAANG interview loop.

1. Design Instagram

The canonical photo-sharing social network problem. The core challenge is the news feed: do you precompute feeds for every user (fan-out on write) or assemble them on demand (fan-out on read)? With fan-out on write, every time someone posts, you insert that post into all their followers' precomputed feed tables. Reads become simple key-value lookups. But a celebrity with 100M followers causes a write storm of 100M inserts on a single post.

The hybrid approach — fan-out on write for regular users (under ~10K followers), on-demand assembly for celebrity posts (merged at read time) — is the standard solution that every interviewer expects.

You'll also discuss photo storage (object storage + CDN), the follower graph, and ranking algorithms that balance recency with predicted engagement.

Full walkthrough: How to Design Instagram

2. Design Twitter / a social media news feed

Arguably the most famous system design question ever asked. The timeline generation problem uses the same hybrid fan-out as Instagram, but Twitter adds a chronological-vs-ranked timeline toggle, a trending topics pipeline (real-time aggregation of hashtag and topic frequency), and Twitter Search (full-text search over billions of tweets using inverted indexes).

The "celebrity problem" is the canonical example of write amplification. When a user with 100M followers tweets, pure fan-out-on-write requires 100M database writes. The hybrid solution avoids this while keeping feed reads fast for the common case. Be ready to explain the threshold logic: "below 10K followers, fan-out on write; above 10K, fan-out on read."

Key trade-off: freshness vs relevance. Chronological feeds are simple but surface boring content. ML-ranked feeds keep engagement high but feel less "real-time."

Full walkthrough: How to Design a Social Media News Feed

3. Design YouTube / Netflix

Video streaming at global scale. The core challenges span the entire pipeline: the video upload and transcoding system (converting one upload into dozens of resolution/codec combinations for different devices and bandwidths), adaptive bitrate streaming (the client dynamically adjusts video quality based on available bandwidth mid-stream), and CDN strategy (caching popular videos at edge nodes in 100+ locations so users stream from nearby servers).

The transcoding pipeline is architecturally interesting: each uploaded video spawns a DAG of encoding tasks executed in parallel on a transcoding cluster. Popular content is pre-transcoded in all formats. Long-tail content might only be transcoded on demand.

Secondary topics: the recommendation engine (collaborative filtering + content-based signals), metadata storage, and the economics of storage vs compute.

This topic is covered in depth in Grokking the System Design Interview.

4. Design a recommendation system

Collaborative filtering ("users who liked X also liked Y"), content-based filtering ("this movie has the same genre and director"), and hybrid approaches at scale. The production architecture is almost always two-stage: a candidate generation step that quickly retrieves ~1,000 items from a pool of millions, followed by a ranking step that scores and sorts those candidates using a more expensive ML model.

Offline training (batch jobs on yesterday's data) is simpler but the model is always one day stale. Online learning (updating in real-time) is fresher but operationally complex. Most production systems use offline training with periodic refresh, supplemented by real-time feature updates.

Full walkthrough: How to Design a Recommendation System

5. Design Reddit

A forum-style platform with voting, nested threaded comments, and dynamic ranking (hot, new, top, controversial). The ranking challenge is distinct from Instagram/Twitter: Reddit scores change constantly as votes arrive, so sorted order is dynamic. The "hot" algorithm weights both score and recency, meaning a highly-voted old post ranks lower than a moderately-voted new post.

The data model is interesting: comments form a tree (each has a parent_id), and rendering nested comments requires efficient tree traversal. Some implementations materialize the comment tree as a pre-computed structure for fast read-time rendering.

Key trade-off: pre-computing rankings (fast reads, slightly stale) vs real-time scoring (accurate but expensive at scale).

Full walkthrough: How to Design a Recommendation System**

Messaging and real-time systems

These questions test persistent connections, delivery guarantees, presence indicators, and real-time fan-out. Especially popular at Meta, Slack, Discord, and collaboration-tool companies.

6. Design WhatsApp / Slack (a chat application)

Real-time messaging at billion-user scale. The persistent connection choice: WebSockets for the primary transport (bidirectional, low overhead) with long polling as a fallback for restrictive firewalls. The message delivery pipeline has three stages: sent (server stores message, acks to sender), delivered (pushed to recipient, recipient acks back), read (recipient opens conversation, sends read receipt). Each stage has retry logic, and offline users' messages queue in the database until they reconnect.

Message ordering uses server-assigned sequence numbers per conversation. Group chats fan out to all online members' WebSockets, with push notifications for offline members. Large groups (1,000+ members) use asynchronous fan-out via a message queue.

Presence ("online" status) is surprisingly hard at scale: 100M concurrent users sending heartbeats every 5 seconds is 20M writes/sec to Redis. The optimization: only push presence to users who have an open conversation with the person.

Full walkthrough: How to Design a Chat Application

7. Design Zoom (a video conferencing system)

The central architecture choice: SFU (Selective Forwarding Unit) vs MCU (Multipoint Control Unit). SFU forwards each participant's stream without decoding — lower server cost but higher client bandwidth (each participant downloads N-1 streams). MCU mixes all streams server-side into one composite stream — lower client bandwidth but much higher server CPU cost. Most modern systems (Zoom, Google Meet) use SFU with simulcast: each participant sends multiple quality levels, and the server forwards the appropriate quality per receiver.

The transport protocol is UDP for media (tolerates dropped frames gracefully) and WebSocket/HTTPS for signaling (joining rooms, muting). This UDP/TCP split is the key insight interviewers listen for.

Full walkthrough: How to Design a Video Conferencing System

8. Design Google Docs (real-time collaborative editor)

Multiple users editing simultaneously without overwriting each other's changes. The core challenge is conflict resolution when two users type at the same position at the same instant.

Operational Transformation (OT) is the classic approach (Google Docs uses it): each edit is transformed against concurrent edits to preserve intention. Requires a central server to order operations. CRDTs (Conflict-Free Replicated Data Types) are the newer alternative (Figma uses them): data structures that merge without coordination. CRDTs enable peer-to-peer sync but use more memory.

Key trade-off: OT requires a central coordinator (simpler reasoning, harder to scale) vs CRDTs (decentralized, more complex to implement for rich text).

Full walkthrough: How to Design a Real-Time Collaborative Editor

9. Design a notification service

Reliably delivering billions of push notifications, emails, and SMS per day. The architecture: an event ingestion layer (Kafka), a routing layer (determines channel based on user preferences), per-channel delivery workers (iOS push, Android push, email, SMS, in-app), and a retry/dead-letter pipeline for failures.

Rate limiting per user ("max 3 push notifications per hour") prevents notification fatigue. Priority levels (transactional like password resets override marketing limits) add complexity. The deduplication problem (same event triggering duplicate notifications) requires idempotent delivery via event IDs.

Key trade-off: at-least-once delivery (safe, some duplicates) vs exactly-once (harder, requires idempotent pipeline).

Full walkthrough: How to Designing a Notification System**

Infrastructure and platform services

These questions test distributed systems primitives — the building blocks underlying every application design. Popular at Google, Amazon, and infrastructure-focused roles.

10. Design a URL shortener (TinyURL)

The quintessential starter problem and the one to practice first. Hash generation strategies (MD5 + base62, counter-based, pre-generated key pools), read-heavy workload optimization (the read-to-write ratio is typically 100:1), caching hot URLs in Redis, and database sharding by key hash.

The capacity math is clean and instructive: 100M new URLs per month, 10B redirects per month, ~3,800 redirect QPS average, ~10K at peak. Redis caching absorbs 80%+ of read traffic. This is a deceptively simple problem that exercises every core concept. If you can design a URL shortener end-to-end with concrete numbers, you can design anything.

Full walkthrough: How to Design a URL Shortener

11. Design a web crawler

Building the front end of a search engine. URL frontier management (priority queue of URLs to crawl with politeness policies limiting per-domain request rate), duplicate detection (Bloom filters tracking billions of already-crawled URLs), distributed crawling (partitioning the URL space across many instances), and content extraction (parsing wildly inconsistent HTML).

Robots.txt compliance and crawl delay respect are important signals to mention. The politeness policy (never more than 1 request/sec per domain) dramatically limits effective throughput, which is why crawlers need thousands of concurrent connections to different domains.

Full walkthrough: How to Design a Web Crawler

12. Design an API rate limiter

The four algorithms: token bucket (most popular, allows bursts, used by Stripe/AWS), leaky bucket (smooth output rate), fixed window counter (simplest, but has the boundary-burst problem), and sliding window (most accurate, fixes the boundary issue). The senior-level discussion: distributed rate limiting across hundreds of API servers, typically via Redis-backed counters with Lua scripts for atomic check-and-decrement.

The failure mode matters: when Redis is unavailable, do you fail closed (deny all, preserve protection) or fail open (allow all, preserve availability)? Most production rate limiters fail open or fall back to per-instance counters.

Full walkthrough: How to Design a Rate Limiter

13. Design a distributed cache (like Redis)

An in-memory key-value store with sharding, replication, eviction policies (LRU, LFU, TTL), and optional persistence (RDB snapshots, AOF logs). Consistent hashing for partition assignment enables adding/removing nodes with minimal key redistribution. Cache stampede (many clients miss on the same key simultaneously) is the failure mode to discuss: mitigate with request coalescing, probabilistic early refresh, or stale-while-revalidate.

Key trade-off: write-through (consistent but slower writes) vs write-back (fast writes, risk of data loss on crash).

Full walkthrough: Design a Distributed Cache (like Redis)

14. Design a search engine

The full stack: crawling, indexing (inverted indexes mapping terms to document IDs), ranking (TF-IDF baseline, PageRank for authority, ML scoring for modern search), and serving results in under 200ms. The indexing architecture is the interesting part: at billions of documents, you shard either by document (each shard indexes a subset, queries fan out to all) or by term (each shard owns certain terms, queries route specifically). Document sharding is more common because rebalancing is easier.

Full walkthrough: How to Build a Search Engine

15. Design typeahead / autocomplete

A trie (prefix tree)-backed service returning suggestions in under 100ms. At each trie node, store the top-K most popular completions for that prefix, pre-computed from search logs. At scale, shard the trie by prefix range and replicate each shard. A background pipeline processes recent search logs, recomputes popularity scores, and pushes updated tries to the serving layer. Personalization adds a lightweight per-user overlay.

Key trade-off: pre-computed top-K (fast, slightly stale) vs real-time scoring at query time (accurate, expensive).

Full walkthrough: Designing Typeahead Suggestion

Storage and data systems

These questions go deep on database internals, consistency models, and data pipelines. Popular at Amazon, Google, and data-infrastructure roles.

16. Design Dropbox / Google Drive (cloud storage)

File synchronization with chunking (splitting files into fixed-size blocks), deduplication (only storing unique blocks), delta sync (uploading only changed blocks on modification), and conflict resolution (what happens when two users edit offline and then sync).

The client-side architecture is as important as the server side. The desktop sync agent monitors local changes, computes block hashes, compares against the server's inventory, and uploads only new or changed blocks. Conflict resolution: last-write-wins (simple, lossy), branching with "conflicted copies" (most common), or CRDTs.

Full walkthrough: How to Design a Cloud Storage Service

17. Design a key-value store (like DynamoDB)

Deeper than the distributed cache. This is about durability, partition tolerance, and CAP trade-offs. Consistent hashing for partitioning, quorum reads/writes for tunable consistency (W + R > N gives strong consistency), vector clocks or last-write-wins for conflict resolution, and hinted handoff for temporary node failures.

This question is essentially "explain the Dynamo paper" — the foundational document for DynamoDB, Cassandra, and Riak. See Amazon Dynamo.

18. Design a unique ID generator (Snowflake)

Globally unique, time-sortable, 64-bit IDs without coordination between nodes. The choices: UUIDs (simple, not sortable), auto-increment (sortable, single point of failure), Snowflake-style (timestamp + machine ID + sequence number: no coordination, sortable, compact), and Flickr ticket servers (centralized blocks of IDs).

Snowflake is the industry standard (Twitter, Discord, Instagram). The key insight: embedding the timestamp in the ID gives time-sortable IDs for free, so range queries on time work efficiently on the primary key.

Full walkthrough: Design Unique ID Generator

19. Design Pastebin

A close cousin of the URL shortener with stored text blobs (arbitrarily large), expiration logic (TTL-based auto-delete), syntax highlighting, and view counts. The architectural difference: paste content is too large for a database row, so store content in object storage (S3) and keep only metadata in the database. Expiration requires either a background cleanup job or TTL-based storage.

A good warm-up problem that covers the same patterns as the URL shortener with added large-object storage complexity.

Full walkthrough: Design Unique ID Generator