Common shapes of design questions
Open in the interactive app: practice, quiz, mock interview →In one minute
- Hundreds of prompts collapse into about six families: user-facing products, infrastructure building blocks, data and analytics pipelines, location and real-time systems, media and large files, and transactional systems with contention.
- Each family has one dominant constraint that decides most of the design: fan-out for products, correctness under failure for infrastructure, throughput with duplicates for data, update rate for location, bandwidth for media, and no double spend for transactions.
- Recognising the family in the first minute tells you where to spend your deep-dive time and which numbers to estimate. A candidate who spends 15 minutes on the feed schema of a payment system has misread the question.
- Many prompts are hybrids (food delivery is location plus transactions plus notifications). Name the dominant constraint aloud and confirm it with the interviewer.
- This chapter maps each family to its deeper lessons in this course, so you can practise by family rather than by memorising designs.
How it works
Product systems
"Design Twitter", "design Instagram", "design Slack", "design a news aggregator". These are the classic prompts. Traffic is read-heavy, often 100 reads per write or more, and the hard problem is getting the right data to many readers cheaply: fan-out on write versus on read, the celebrity problem, ranking, and keeping a timeline cache warm. Scoping matters most here because the feature list is endless. Go deeper with Design FB News Feed, Design Slack, Fanout, and High Read Traffic.
Infrastructure building blocks
"Design a rate limiter", "design a distributed cache", "design a key-value store", "design a job scheduler", "design an API gateway". There is no product to scope; the interviewer wants internals. The dominant constraint is correctness under partial failure: what happens when a node dies mid-write, when the network partitions, when two nodes think they are the leader. Expect replication, consistent hashing, quorums, leases and clock skew; the Dynamo paper is the usual reference point for most of these ideas in one system (Dynamo). See Design Rate Limiter, Design Key-Value Store, Design Distributed Cache and Design Job Scheduler.
Data and analytics pipelines
"Design an ad click aggregator", "design top-k trending", "design a metrics system", "design a web crawler". Writes dominate, often by orders of magnitude, and nobody reads individual events. The constraint is sustained throughput while handling late, duplicated and out-of-order events. Deep dives cover partitioned logs, windowed aggregation, exactly-once versus at-least-once with idempotent sinks, and approximate structures such as Count-Min Sketch. See Design Ad Click Aggregator, Design Top K, Design Web Crawler and Distributed Counting.
Location and real-time systems
"Design Uber", "design a food delivery service", "find nearby friends". The constraint is a high rate of small position updates combined with spatial queries: a million drivers sending a location every 4 seconds is 250,000 writes per second, none of which needs to be durable for long. Deep dives cover geohash or S2 cells (S2 numbers 31 levels of cells along a Hilbert curve with 64-bit IDs, so nearby cells get nearby IDs (S2 docs)), in-memory spatial indexes, and pushing updates over WebSockets. See Design Uber, Design Food Delivery Service, Handling Location Data and Realtime Updates.
Media and large files
"Design YouTube", "design TikTok", "design Dropbox". The constraint is bytes: upload bandwidth, transcoding compute, storage cost, and CDN egress. The metadata service is easy; the interesting parts are resumable chunked uploads, a transcoding pipeline, adaptive bitrate streaming (HLS or DASH, where the player picks a rendition per segment from a playlist (RFC 8216)), and cache hit ratio at the edge. See Design YouTube, Design TikTok, Handling Large Files and Media Streaming.
Transactional systems with contention
"Design a payment system", "design Ticketmaster", "design a flash sale", "design an auction", "design Airbnb booking". Volume is often modest, but correctness is non-negotiable: never charge twice, never sell the same seat twice. Deep dives cover idempotency keys (Stripe, for example, stores the first response per key, rejects a reuse with different parameters, and may prune keys after 24 hours (Stripe docs)), row locks versus optimistic concurrency, reservations with expiry, ledgers, and what happens when the payment provider times out. See Design Payment System, Design Flash Sale, Design Movie Booking System, Design Online Auction System and Preventing Double Booking.
Hybrids and twists
Real prompts mix families. Food delivery is location plus a transaction plus notifications; Google Docs is a product whose hard part is real-time collaborative editing (Design Google Docs). Interviewers also twist a familiar prompt into another family: "design a URL shortener" is a product question until they add "and show click counts per hour per country", which turns it into a data pipeline. When you hear a twist, say which constraint just changed.
Formats that are not this round
Some prompts look like system design but belong to a different interview. Low-level or object-oriented design asks for classes and interfaces, not services; ML system design asks about modelling and features; and frontend design is its own track (Hello Interview). Companies also split the system design round by role. Meta's Product Architecture round, for product engineers, uses user-facing prompts such as a news feed or Ticketmaster rather than a load balancer, and expects the whole system to be built from cloud-style managed components (Hello Interview). Ask the recruiter which variant you will get, because it decides which of the families below to practise most.
Down the stack
Layer 1The contract
What the interviewer scores is the same rubric for every type, but the weight shifts. For product questions most evidence comes from scoping and data modelling, because that is where candidates differ. For infrastructure questions it comes from depth and failure reasoning; a vague answer on replication is fatal. For data pipelines it is delivery semantics and throughput arithmetic. For transactional systems it is correctness: an interviewer who hears "we'll retry the charge" with no idempotency key will usually stop there. Misreading the type means spending your 45 minutes collecting evidence on the dimension that carries the least weight.
Layer 2The mechanism
Each family has a characteristic mechanism that the deep dive usually reaches. Product: a precomputed per-user timeline in a cache, with a hybrid of push for normal users and pull for accounts with millions of followers. Infrastructure: a consistent-hash ring with virtual nodes, replication factor 3, and quorum reads and writes (R + W > N), which Cassandra exposes as per-request consistency levels such as QUORUM and LOCAL_QUORUM (Cassandra docs). Data: a partitioned log such as Kafka feeding a stream processor that keeps windowed state, checkpoints it, and writes to a sink with idempotent upserts keyed by (window, key). Location: a grid index (geohash prefix or S2 cell ID) held in memory and sharded by region, queried by scanning the cell and its neighbours. Media: chunked uploads to object storage, a DAG of transcoding jobs, and HLS or DASH manifests that let the player switch bitrate per segment. Transactional: a state machine per order or seat, guarded by a conditional write (UPDATE seats SET held_by = ? WHERE id = ? AND held_by IS NULL) and an idempotency table.
Layer 3The machine
The dominant constraint of each family maps to a physical limit. Products hit memory: 500 million users times 800 timeline entries of 8 bytes is about 3.2 TB of cache, so you need dozens of large cache nodes. Infrastructure hits the latency of durability: an fsync on a good NVMe drive costs tens of microseconds to a millisecond (a 2026 cloud measurement put an 8 KiB write plus fsync at about 300 us (Napkin Math)), and a quorum write adds a network round trip of about 0.5 ms within a data centre. Data pipelines hit sequential throughput: a single Kafka partition typically takes tens of MB per second of produce traffic, depending on batching, compression, acks and replication (Confluent), so 1 GB per second of clicks needs dozens of partitions. Location hits write rate into memory: 250,000 updates per second is easy for a sharded in-memory index but brutal for a B-tree on disk. Media hits the network: a 4 Mbit/s stream to one million concurrent viewers is 4 Tbit/s, which only a CDN can serve. Transactions hit lock contention: a single hot row can commit only a few hundred to a few thousand updates per second, however large the machine.
Why it's built this way
Interviewers have one hour, so they choose prompts that concentrate one hard problem, and each hard problem comes from one scarce resource. So the family tells you which resource is scarce, the scarce resource tells you which numbers to estimate, and the numbers tell you which mechanism to deep dive.
Diagram
flowchart TD
P["Prompt"] --> K["Spot keywords and verbs"]
K --> F1["Product: fan-out"]
K --> F2["Infrastructure: failure"]
K --> F3["Data: throughput, duplicates"]
K --> F4["Location: update rate"]
K --> F5["Media: bandwidth"]
K --> F6["Transactional: contention"]
F1 --> E["Estimate the scarce resource"]
F2 --> E
F3 --> E
F4 --> E
F5 --> E
F6 --> E
E --> D["Pick deep dives"]Worked example
Prompt: "Design a system that sells 10,000 concert tickets that go on sale at 10:00, with 2 million fans waiting."
Classify. The keywords are "sells", "tickets" and "go on sale": transactional with contention, plus a traffic spike. The dominant constraint is never selling a seat twice while the front door survives a surge.
Estimate the scarce resource. Two million fans refreshing every 2 seconds is 1 million requests per second at the edge, but only 10,000 successful purchases. If all of them tried to lock seat rows at once, a hot section of 500 seats would see thousands of conflicting writes per second on a handful of rows.
Choose deep dives that match. First, a virtual waiting room that admits, say, 2,000 users per minute, which converts the spike into a steady flow. Second, seat holds: a conditional update sets held_by and hold_expires_at for 10 minutes, and expired holds are released by a sweeper. Third, payment: an idempotency key per hold so a retried checkout cannot charge twice.
What to skip: profiles, recommendations and the artist page get one sentence each. For "design Instagram" those same minutes would go to fan-out, and "idempotency" might never come up.
In the wild
- Ticketmaster, 2022: the Eras Tour presale. Over 3.5 million fans pre-registered and about 1.5 million received codes, but bots and fans without codes drove 3.5 billion system requests, four times the previous peak. Ticketmaster slowed and postponed sales to keep the queues stable, estimated that about 15% of interactions hit errors (including passcode failures that dropped carted tickets), and still sold over 2 million tickets that day. It is the transactional family with a surge on top, exactly the shape of this chapter's worked example (Ticketmaster, archived).
- Segment, 2017: duplicates are the data family's normal state. About 0.6% of events ingested over four weeks were duplicates, mostly from clients on flaky networks retrying. Segment partitioned Kafka by message ID and gave each worker a RocksDB store of IDs seen in a four-week window, reaching about 60 billion keys and 1.5 TB after three months (Twilio Segment).
- Tinder, 2019: location load is uneven. One five-shard index became costly, so Tinder scored load per S2 cell, packed cells into 40 to 100 geoshards in Hilbert order, and handled 20 times the computation. Different language libraries produced different 64-bit IDs for the same cell, so they stored string tokens instead (Tinder Engineering).
Trade-offs
| Family | Dominant constraint | Typical deep dives | Common trap |
|---|---|---|---|
| Product | Read fan-out and data model | Timeline cache, celebrity problem, ranking | Scoping too many features |
| Infrastructure | Correctness under partial failure | Replication, consistent hashing, leases | Hand-waving failure cases |
| Data pipeline | Throughput with late and duplicate events | Partitioned log, windows, idempotent sinks | Designing a read API nobody needs |
| Location | Update rate plus spatial query | Geohash or S2 index, sharding by region | Persisting every ping durably |
| Media | Bandwidth and storage cost | Chunked upload, transcoding, CDN | Over-designing metadata |
| Transactional | No double spend under contention | Conditional writes, holds, idempotency | Retries without idempotency keys |
Pitfalls in production
These misclassifications happen in real projects too, not only in interviews:
- Treating a pipeline as a product. Teams build a request/response API over raw events and fall over at the first marketing campaign. Fix: identify write-dominant workloads early and put a log in front.
- Treating a transaction as a feed. Eventual consistency on inventory leads to oversold stock. Fix: find the invariant ("seats sold is at most capacity") and protect it with a conditional write.
- Ignoring the hybrid. A delivery app designed only as a location system lacks a durable order state machine, so orders are lost when a dispatcher restarts. Fix: list every family the system touches and give each its own store.
- Over-durable location data. Writing every GPS ping to a replicated database is costly and useless. Fix: keep the live position in memory and sample to durable storage for history.
Leadership lens
- In a design review, ask the author to name the family and the one invariant or scarce resource first; disagreements about the design are often disagreements about this.
- Staff the team to match the family: transactional systems need engineers comfortable with concurrency and auditing, media systems need people who understand CDNs and cost.
- When building an interview loop, rotate prompts across families so you are not only hiring people good at feeds.
Check yourself
Why is a URL shortener with per-hour click analytics harder than one without?
Show answer
The analytics turn it into a write-heavy data pipeline: every redirect becomes an event that must be aggregated with late and duplicate handling, which needs a log and a stream aggregator rather than a simple counter.
What single question tells you whether a prompt is transactional?
Show answer
Is there an invariant that must never be violated even briefly, such as "never sell more than capacity" or "never charge twice"? If so, correctness under contention dominates.
Why do location systems usually keep live positions in memory?
Show answer
Updates arrive at hundreds of thousands per second and are only valid for seconds, so durable replicated writes cost far more than the data is worth; history can be sampled separately.
An interviewer gives you "design Dropbox". Where should most of your estimates go?
Show answer
Into bytes: upload and download bandwidth, storage growth, and deduplication savings, since metadata volume is small compared with file content.
Sources and further study
Primary
- RFC 8216: HTTP Live Streaming: the playlist and segment model behind adaptive bitrate in media prompts.
- S2 cell hierarchy (S2 Geometry): how spherical cells and Hilbert-curve IDs make spatial lookups into range scans.
Systems docs
- Cassandra: Dynamo architecture: consistency levels, W + R > RF and last-write-wins, the core of infrastructure prompts.
- Stripe: Idempotent requests: a real idempotency-key contract for the transactional family.
- Confluent: choosing the number of partitions: per-partition throughput for sizing data pipelines.
Books
- System Design Interview – An Insider's Guide, Volume 1, Alex Xu, chapters 4 to 15: rate limiter, key-value store, web crawler, news feed, chat, YouTube and Google Drive, spanning most families here.
- System Design Interview – An Insider's Guide, Volume 2, Alex Xu and Sahn Lam, chapters 1 to 13: proximity and maps (location), ad click aggregation (data), hotel reservation, payments and digital wallet (transactional).
- Designing Data-Intensive Applications (1st edition), Martin Kleppmann, chapter 1 "Reliable, Scalable, and Maintainable Applications": describing load and performance, the step before naming the scarce resource.
Other curricula
- System Design in a Hurry: Introduction (Hello Interview): splits interviews into product design and infrastructure design, and separates out low-level and ML design.
Watch
- System Design Interview: Design Ticketmaster w/ a Ex-Meta Staff Engineer (Hello Interview): a transactional, contention-dominated prompt worked end to end.
- Design an Ad Click Aggregator w/ a Ex-Meta Staff Engineer (Hello Interview): a data-pipeline prompt, useful to contrast with the transactional one.
- Design a Distributed Rate Limiter (Hello Interview): an infrastructure building block where internals and failure handling carry the interview.
Free resources
- The System Design Primer: sample designs from several families with worked solutions.
- System Design in a Hurry: Core Concepts (Hello Interview): the recurring building blocks that the families draw on.
- Amazon's Dynamo (All Things Distributed): the canonical reading for infrastructure-type prompts.
- The Amazon Builders' Library: production write-ups on timeouts, retries, idempotency and load shedding that cover the transactional and infrastructure families.
- Napkin Math: reference numbers for the scarce resource in each family.