Top 30 System Design Questions, Ranked by How Often They're Asked 

Twelve banks pulled, eleven survived the rules. What actually gets asked, with receipts, and the eight patterns underneath the whole canon.

Tally marks next to interview flashcards, which is the whole article in one image: someone finally counted which system design questions actually get asked, instead of guessing.

Every List Is a Catalog. Nobody Counts.

I watched a strong candidate commit to push fan-out, arms crossed, diagram finished, marker down. The interviewer let the silence sit, then asked: "And when someone with a hundred million followers posts?" Six quiet minutes of half-erased arrows followed. The debrief took five: strong coder, wrong instinct, no hire. He'd prepped hard, just from a catalog that never told him what mattered.

Page one of Google is full of those catalogs: 30, 40, 50 questions, no explanation of the ordering, because there isn't one. The nearest anyone gets to data is IGotAnOffer's Glassdoor sorting and one Medium post built on "50 interviews in 12 months." Even PracHub, where I do nearly all of my own practice, and the first place I'd point a friend, is doing a different job: a live, company-tagged bank of about a thousand design questions. A very good bank. Still a bank, not a ranking.

So I counted. If you've only got three free weekends before an onsite, I'd rather they go into the right ten questions.

How I Counted

Twelve public banks pulled in the last week of June 2026, every distinct high-level design prompt extracted. InterviewBit turned out to be theory flashcards and got dropped; Exponent and the Medium post only showed part of their contents, and I counted what was visible. That leaves eleven usable lists, PracHub's thousand company-tagged questions among them (disclosure: it's where I practice, so discount my fondness). The merge left a little over forty distinct prompts. Thirty made the cut.

One thing about me first, since the cards lean on my judgment: two-hundred-some loops on the interviewer side across three companies, plus enough time on the candidate side to know what a whiteboard marker cap tastes like. The ranking comes from the count; the traps and signals come from seat time.

The rules, exactly as applied:

counting_rules.yaml (applied 2026-06-30)

unit: one mention per source, ignoring the source's own ordering

merge_synonyms:

url_shortener: [tinyurl, bitly, pastebin]   # pastebin is this question with blobs

chat_app: [whatsapp, messenger, telegram, slack]

news_feed: [twitter, x, facebook_feed]

video_streaming: [youtube, netflix]

instagram stays separate. the media pipeline changes the question

exclude:

lld_ood: [parking_lot, elevator, vending_machine, chess]  # different interview

pure_theory: [cap_theorem, consistent_hashing]            # concepts, not prompts

tie_breaks:

1: company_sourced_receipts   # Glassdoor-by-company data, PracHub company tags

2: recency_of_source_update

3: editor_judgment            # every use is flagged on the card

Quick caveats. Mention count is not ask-frequency; it measures how hard the prep world agrees a question matters. Glassdoor skews big-tech. And ties below rank ten get broken by receipts and recency, no ceremony.

It's a proxy. It's also the only number anyone on page one has bothered to produce.

How to Read the Tiers

The tiers are just the ranking cut into threes. Tier 1 is the top ten by count. Ranks eleven through twenty are Tier 2. Tier 3 is the rotation: the cards you pull the night you find out your interviewer works on the storage team. Editor judgment overrode a raw count exactly twice, at #15 and #30, and both cards say so.

Every card runs six fields: what it tests, who asks it, the trap that catches most of us (I've stepped in a few myself), the senior signal, a good-to-know for extra depth, and a spoke link into the deep-dive hub. Until those pages exist, the spokes are IOUs.

Attribution, so the cards read clean: a company named with no source attached is the Glassdoor data talking. Where a receipt comes from PracHub's tags instead, the card says so.

Tier 1: The Ten You're Most Likely to Get

1. Design a URL Shortener (Bitly)

Every countable list carries it. The only place it's missing is the page that didn't survive the rules.

• What it tests: Capacity math you can defend, base62 vs. hashing (collisions), read-heavy caching, and knowing a 301 kills your click analytics while a 302 preserves them.
• Who asks it: Everyone, phone screens especially. Amazon hasn't retired it in a decade.
• The trap: Sharding a dataset that fits on one machine. Most of us have done it. A billion short links at ~500 bytes each is half a terabyte. Worth saying out loud before anyone reaches for Cassandra.
• The senior signal: Asking who consumes the click data before designing anything, and pre-generating key ranges instead of praying about collisions.
• Good to know: Seven characters of base62 is about 3.5 trillion keys, enough to never reuse one. Cache hit rate is basically the whole latency story here. Reads outnumber writes 100:1 or worse.
• Spoke: /system-design/url-shortener

2. Design a Chat App (WhatsApp)

• What it tests: Long-lived connections at scale, meaning WebSockets behind a load balancer, per-conversation ordering, delivery states, group fan-out.
• Who asks it: Meta. OpenAI has asked "design Slack," and PracHub carries an Anthropic-tagged 1:1 chat version.
• The trap: A partition per user is not a plan. Ordering lives inside each conversation, and the message hits storage before the ack goes out.
• The senior signal: Client-generated message IDs for idempotent sends, per-conversation sequence numbers, and the warning that presence melts you long before messages do.
• Good to know: WhatsApp famously ran about two million connections per box on tuned Erlang and FreeBSD. Nobody expects you to match that. They do expect an answer for where connection state lives when a server dies, and "the client reconnects and resyncs from its last ack" is the honest one.
• Spoke: /system-design/chat

Ask a candidate how a message gets from phone A to phone B. Count the seconds until someone says "Kafka." I've stopped being surprised.

3. Design a News Feed (Twitter / Facebook)

• What it tests: Fan-out on write vs. fan-out on read, the celebrity problem, the feed as a merge of cached lists, ranking vs. recency.
• Who asks it: Meta's product track runs on it. Google asks the news-aggregator flavor.
• The trap: Committing to push fan-out. That's the candidate from the top of this piece, and the 100M-follower follow-up is coming either way.
• The senior signal: Hybrid fan-out with a stated follower-count threshold, and honest cost math on precompute vs. read-time merge.
• Good to know: The classic hybrid puts celebrity accounts on pull and everyone else on push, and the feed cache stores post IDs, never post bodies. Hydration happens at read time. That's the only thing keeping a hot feed from duplicating the whole posts table.
• Spoke: /system-design/news-feed

4. Design Video Streaming (YouTube / Netflix)

• What it tests: Upload, transcode, deliver. Three systems. Chunked uploads, an async transcoding DAG, adaptive bitrate (HLS/DASH), metadata split from blobs.
• Who asks it: Google. Apple asks the Netflix flavor.
• The trap: Thirty minutes on upload when the interviewer wanted delivery. One prompt, two questions. It's fair to just ask which half they want.
• The senior signal: Treat transcoding as a fan-out DAG that can retry one chunk without redoing the whole movie. The CDN contract is the actual bill; numbers help more than adjectives here.
• Good to know: One 10-minute 1080p upload becomes dozens of transcode tasks across resolutions and codecs. Retrying one chunk instead of the whole movie is the DAG's entire job. HLS segments run roughly 2 to 10 seconds, and that segment length sets the floor on live latency.
• Spoke: /system-design/video-streaming

5. Design Ride Sharing (Uber)

• What it tests: Geospatial indexing (geohash, H3, or quadtrees; picking one is most of the battle), high-frequency location writes, matching under staleness.
• Who asks it: Uber and Lyft for obvious reasons, Microsoft for less obvious ones.
• The trap: Every driver ping written to a durable store. A position from five minutes ago is garbage. Live locations can sit in RAM with TTLs and quietly expire.
• The senior signal: Cell-based sharding, and a matching flow that tolerates slightly stale positions instead of locking everything in sight.
• Good to know: Geohash precision 5 is a cell about 5km across; precision 6 is closer to 1km. The right choice depends on city density. A million drivers pinging every 4 seconds is 250k writes per second, which is the number that ends the Postgres conversation.
• Spoke: /system-design/ride-sharing

6. Design Typeahead / Autocomplete

• What it tests: Sub-100ms reads at p99, precomputed top-k per prefix, and the offline pipeline that keeps suggestions fresh.
• Who asks it: Meta and Google, both.
• The trap: Drawing a trie and stopping. The trie is the easy half; updating it from a live query stream without rebuilding the world is the question.
• The senior signal: Top-k cached per prefix and a pipeline that samples instead of counting everything. Personalization gets named, then gently scoped out.
• Good to know: The latency budget allows exactly one network hop. Precompute the top 5 to 10 suggestions per prefix and serve them as a single key. Freshness usually comes from layering a small real-time trending signal over an hours-old batch build.
• Spoke: /system-design/typeahead

7. Design a Rate Limiter

My favorite question to ask, if I'm honest: small enough to finish, deep enough to fail.

• What it tests: Token bucket vs. sliding window, atomic counters across nodes, and a position on fail-open vs. fail-closed when the limiter itself dies.
• Who asks it: Infra loops everywhere. OpenAI, per PracHub's tag, where it's one of the most-practiced questions in the whole bank.
• The trap: The snippet below. We shipped it. It cleared review.
• The senior signal: One atomic Lua script (or Redis 7's EXPIRE NX), a plan for hot keys, and a stated policy: fail open, page loudly.
• Good to know: Token bucket allows controlled bursts, a sliding-window log is exact but memory-hungry, and the sliding-window counter is the compromise most teams ship. The published industry stance, Stripe's included, is to fail open: serving a little extra traffic beats serving none.
• Spoke: /system-design/rate-limiter

Looks fine. Locked a partner out for an entire weekend.

count = redis.incr(f"rl:{key}:{minute}")

if count == 1:

A process died between INCR and EXPIRE during a deploy.

The key now lives forever, the counter never resets, and

every request from that key gets rejected until a human

deletes it by hand. That human was me.

redis.expire(f"rl:{key}:{minute}", 60)

if count > LIMIT:

reject()

8. Design File Sync (Dropbox)

• What it tests: Chunk, hash, dedup, and keep the metadata DB alive under a million small files. Conflict handling separates the real designs from the recited ones.
• Who asks it: Microsoft, for both Dropbox and iCloud.
• The trap: Re-uploading whole files on save, and last-write-wins on conflicts. On a shared folder, LWW is data loss you designed on purpose.
• The senior signal: Fixed-size chunks hashed client-side, version chains instead of overwrites, and conflicts surfaced to users.
• Good to know: Dropbox historically chunked at 4MB with a hash per chunk. An identical chunk uploads once, ever, across all users. Delta sync means editing one page of a 100MB document moves kilobytes, and rsync's rolling checksum is the ancestral idea worth name-dropping.
• Spoke: /system-design/file-sync

9. Design a Web Crawler

• What it tests: BFS at planetary scale, politeness (robots.txt, per-domain caps), URL and content dedup, frontier prioritization.
• Who asks it: Google, historically and currently.
• The trap: Skipping politeness. No per-domain cap means you built a DDoS tool with a mission statement. We pointed an eager crawler at a partner's staging box years ago. Their on-call phoned ours.
• The senior signal: Partition the frontier into per-domain priority queues, bloom-filter the seen set, and state the tradeoff plainly: some pages get skipped, and that's fine.
• Good to know: The frontier is the real design. Mercator's two-level scheme, priority queues feeding per-host queues, is decades old and still the standard answer. A bloom filter at 1% false positives holds a billion URLs in a couple of gigabytes of RAM.
• Spoke: /system-design/web-crawler

10. Design a Notification System

• What it tests: Multi-channel fan-out (push, SMS, email), provider failure, dedup, per-user rate control, priority classes.
• Who asks it: Amazon. Also the question interviewers reach for when they suspect you memorized the feed answer.
• The trap: Trusting APNs, FCM, and Twilio to be up. No idempotency key on send means duplicate pages.
• The senior signal: At-least-once delivery with dedup at the edge, and a circuit breaker per provider. OTPs never queue behind marketing blasts.
• Good to know: APNs and FCM throttle and drop by design. It's written into the contract. Persist notification state before the send attempt, dedupe on a client-visible ID, and give priority classes separate queues so the login code rides an express lane.
• Spoke: /system-design/notifications

Tier 2: Where Company Flavor Takes Over

Tier 2 is where the interviewer's org chart starts showing. The prompts stay public. The follow-ups depend on whose infra you're sitting in.

11. Design a Proximity Service (Yelp)

• What it tests: Geo again, but read-heavy: static businesses and moving friends are different problems in the same index.
• Who asks it: Uber, as "nearby places." Seven of the 11 lists, same as notifications; Amazon's broader receipt won the boundary tie.
• The trap: Computing distance to everything in the city on every request.
• The senior signal: Geohash precision chosen with numbers, caching per cell, separate paths for static and live entities.
• Good to know: Static points of interest change slowly. Precomputed cell-to-business lists, cached hard, cover most of the read load, and Yelp-scale is only tens of millions of rows. The moment entities move, the write pattern flips and you're back on the Uber card.
• Spoke: /system-design/proximity

12. Design Instagram

• What it tests: The feed problem plus a media pipeline, and in the room, the photos are usually the hard part.
• Who asks it: Six of the lists carry it, with Meta and Microsoft receipts on top.
• The trap: Designing it as feed-only or storage-only instead of both with a clean seam.
• The senior signal: Precompute thumbnails at upload. Serve media from the CDN, metadata from cache, and say which half you're designing first.
• Good to know: Media lands in blob storage under an immutable URL, metadata goes to a relational store, and thumbnails get cut at write time in three or four sizes. Early Instagram was literally Postgres, S3, and memcached; the shape still holds at a much bigger scale.
• Spoke: /system-design/instagram

13. Design Ticketmaster

This is the card I carry the most personal scar tissue on.

• What it tests: Contended inventory. Nobody gets seat 14B twice, holds expire on TTL, the on-sale spike is 100x baseline.
• Who asks it: Amazon and Google receipts sit on top of the count. Six of the 11.
• The trap: Seat 14B, sold twice. That's what pessimistic locks bought us during an arena on-sale: SELECT FOR UPDATE on seat rows, the lock queue backed up into the payment path, and holds expired while cards were mid-auth. A week of support tickets.
• The senior signal: Model the hold as a state machine and let TTLs do the killing. Idempotent payment confirmation, and a virtual waiting room in the first diagram, not the last.
• Good to know: A hold is just a row with a state and an expires_at, plus a sweeper. The waiting room is rate limiting in a costume: admit N users per second into the store. And the on-sale spike is brutal but mostly reads, which is a caching problem, not a locking one.
• Spoke: /system-design/ticketmaster

14. Design a Distributed Cache

• What it tests: Consistent hashing, LRU approximations, hot keys, thundering herds.
• Who asks it: Google and Amazon. Six of the 11.
• The trap: Cache-aside, recited like it's the whole answer. The follow-up is nearly always a stampede on one key.
• The senior signal: Request coalescing. One line of config, and it was the difference between a blip and a Saturday. TTL jitter and negative caching round it out.
• Good to know: Production Redis approximates LRU by sampling a handful of keys rather than tracking a perfect list; exact LRU isn't worth the memory. Coalescing means one loader per key per expiry window, and everyone else waits on that single flight instead of hammering the database.
• Spoke: /system-design/distributed-cache

15. Design a Payment System (Stripe)

• What it tests: Idempotency keys end to end, a double-entry ledger, retries against a flaky processor, and reconciliation as a subsystem with an owner and a pager.
• Who asks it: Every fintech loop I've seen. Six of the 11, and one judgment call, flagged: ranked above Docs on loop volume outside big tech.
• The trap: Promising exactly-once. Also floats for money. I lost most of a quarter-end to a ledger that drifted eleven cents across two million rows because someone stored dollars as doubles. Integer cents. Always.
• The senior signal: Idempotency at the API boundary, append-only ledger entries, webhooks with signed retries.
• Good to know: The idempotency key is client-generated and stored alongside the response, so a retry replays the answer instead of the charge; Stripe keeps keys for 24 hours. Double-entry means every movement writes two rows that must sum to zero, which turns "did we lose money" into a query.
• Spoke: /system-design/payments

16. Design Google Docs

• What it tests: Concurrent editing (OT vs. CRDT), presence, cursors, offline merge.
• Who asks it: Google-adjacent loops. Six of the 11, always filed under hard.
• The trap: Deriving operational transforms live at a whiteboard. People have PhDs in this. We inherited a homegrown OT engine at an acquisition; two fast typists could fork a document permanently, and we found out from a law firm.
• The senior signal: CRDTs for offline-first, a central sequencer as the boring alternative, and a kind word for why locks make a worse product.
• Good to know: OT transforms each operation against concurrent ones, and it's what Google Docs runs. CRDTs make operations commutative so order stops mattering, roughly the direction Figma went. The answer that fits in 45 minutes is a central sequencer with versioned operations.
• Spoke: /system-design/collab-editing

17. Design Google Maps

• What it tests: Tiles and routing as separate systems, precomputed graph shards, ETA with live traffic folded in.
• Who asks it: Google. Five of the 11 bother with it.
• The trap: Waving "Dijkstra" at a graph with billions of edges and hoping.
• The senior signal: It helps to name the tension out loud: precompute everything and serve stale, or compute fresh and blow the latency budget. Contraction hierarchies earn a nod, and tiles live on the CDN.
• Good to know: Contraction hierarchies precompute shortcut edges so continent-scale routes resolve in milliseconds, and live traffic then re-weights edges near you rather than recomputing the world. Tiles are just images or vector bundles on a CDN, keyed by zoom, x, and y.
• Spoke: /system-design/maps

18. Design an Ad Click Aggregator

• What it tests: Streaming counts at billions of events a day, late and duplicate events, reconciliation against batch.
• Who asks it: Ad-revenue companies; the AdSense version is the one prep sites teach. Five of the 11.
• The trap: "Kafka plus Flink" with no answer for watermarks or replay.
• The senior signal: Make the sinks idempotent, reconcile against a nightly batch, and bring up click fraud before the interviewer does.
• Good to know: A watermark is a moving promise about how late an event can arrive and still count; anything later belongs to the batch reconcile. Idempotent sinks mean the same click ID can arrive three times and count once. Exact numbers pay invoices. Batch wins every argument with streaming.
• Spoke: /system-design/ad-aggregator

19. Design a Metrics System (Datadog)

• What it tests: Time-series ingest, downsampling tiers, cardinality explosions, and alerting that runs on its own path.
• Who asks it: Infra orgs, and Datadog itself. Five of the 11.
• The trap: One retention tier forever. The storage math catches up in week two.
• The senior signal: Downsample by age and cap tag cardinality hard. Alert evaluation stays off the ad-hoc query path.
• Good to know: Cardinality multiplies: 100 services times 50 endpoints times 1,000 hosts is five million series before someone accidentally adds a user-ID tag. A sane retention ladder looks like raw for a day, one-minute rollups for a month, one-hour rollups kept long-term.
• Spoke: /system-design/metrics

20. Design a Job Scheduler

• What it tests: At-least-once execution, misfire policy, workers claiming jobs without double-running them.
• Who asks it: Platform teams. The canonical version is Airflow. Five of the 11.
• The trap: Cron on one box with retries. Ours died mid-payroll run, a Tuesday: half the batch ran twice, the other half never ran. Idempotency stopped being a nice-to-have that afternoon.
• The senior signal: Push idempotency onto job authors as a contract. Visibility timeouts. A dead-letter queue that someone actually owns.
• Good to know: Claiming a job is a compare-and-swap: UPDATE jobs SET state='running' WHERE id=? AND state='pending', and the row count tells you if you won. The visibility timeout idea comes straight from SQS: a claimed job that goes silent returns to the pool on its own.
• Spoke: /system-design/job-scheduler

Tier 3: The Rotation

Two to four lists each. These tend to show up in specialized loops, senior rounds, or when the interviewer is bored of the top ten.

21. Design a Message Queue

• What it tests: Log-structured storage, partitions, consumer groups, and the redelivery semantics everyone hand-waves.
• Who asks it: Shows up on four lists, all of them infra-flavored.
• The trap: Promising exactly-once across arbitrary consumers, casually.
• The senior signal: Consumers own their offsets. Replication needs an in-sync set. And it helps to have a backpressure answer that isn't "add more consumers."
• Good to know: Kafka's core trick is sequential disk I/O plus the OS page cache. That's how a plain log outruns fancier structures. Brokers stay dumb, consumers track their own offsets, and redelivery means duplicates by design. Dedup is the consumer's job.
• Spoke: /system-design/message-queue

22. Design Food Delivery (DoorDash)

• What it tests: A three-sided marketplace: geo, dispatch, inventory, prep-time prediction.
• Who asks it: Amazon includes it in their set. Four of the 11.
• The trap: Uber-with-restaurants, minus the inventory problem. The failure mode is physical: cold fries, a driver reassigned twice mid-route, a prep-time model that lies every Friday night.
• The senior signal: Dispatch keeps re-optimizing until pickup, and deciding up front how consistent the cart really needs to be saves you the follow-up.
• Good to know: Dispatch re-solves an assignment problem every few seconds, batching orders and couriers instead of matching greedily one at a time. Prep-time prediction is a regression model, and its error bars decide who waits: the courier or the food.
• Spoke: /system-design/food-delivery

23. Design a Stock Exchange

• What it tests: A matching engine, price-time priority, determinism, event-sourced recovery.
• Who asks it: Trading firms and fintechs, usually modeled on Robinhood. Four of the 11.
• The trap: Distributing the matching engine. Real ones are single-threaded on purpose.
• The senior signal: Match in memory, journal every input to a replicated log. Risk checks stay on the hot path even though they cost microseconds.
• Good to know: LMAX published the blueprint: a single-threaded matcher over an in-memory book, every input journaled. Replay the log and you get the exact same book back. Determinism is why wall clocks and hash-iteration order are banned from the matching path.
• Spoke: /system-design/exchange

24. Design ChatGPT (LLM Serving)

• What it tests: GPU bin-packing, KV-cache reuse, token streaming, queueing under bursty demand.
• Who asks it: OpenAI and Anthropic keep asking it. Three of the 11, and recency pulled it to the top of the three-mention pile. PracHub's bank already carries the 2026 variants, a prompt playground tagged Anthropic and Sora-style job orchestration tagged Google and OpenAI. Expect it to climb again next year.
• The trap: Treating inference like a stateless web service. This prompt didn't exist when I started interviewing; now it opens senior infra loops.
• The senior signal: Continuous batching, prefix caching, and per-tenant fairness so one customer's batch job doesn't starve everyone else's chat.
• Good to know: Continuous batching admits new requests at token boundaries instead of waiting for a batch to drain, which is most of the throughput win. Time-to-first-token and tokens-per-second are separate SLOs with different levers, and prefix caching only pays off when tenants share prompt prefixes.
• Spoke: /system-design/llm-serving

Somewhere right now, a staff engineer is turning whatever their team shipped last quarter into next year's canonical question. That's how the canon has always grown.

25. Design Hotel Booking (Airbnb)

• What it tests: Date-range availability search plus booking contention.
• Who asks it: Travel companies. Alex Xu gave it its own chapter. Three of the 11.
• The trap: Locking rows to serve search. Search is allowed to lie by a few minutes as long as booking tells the truth.
• The senior signal: Availability as a materialized calendar, and overbooking as a business decision with somebody's name on it. It's worth finding out whose.
• Good to know: Model availability as counts per room type per date, not one row per physical room; booking then decrements atomically across the date range in a single transaction. Search reads a denormalized copy that's allowed to lag.
• Spoke: /system-design/hotel-booking

26. Design a Key-Value Store

• What it tests: Can you pick CP or AP and live with it? The rest is partitioning, replication, and quorum math.
• Who asks it: Database-adjacent loops, senior rounds, and anyone who has read the Dynamo paper recently enough to be dangerous. Three of the 11.
• The trap: The Dynamo paper, recited without choosing CP or AP. The fumble I see most often: "vector clocks," said confidently, then silence when asked what the client does with two siblings.
• The senior signal: Pick one, then defend it with a specific failure scenario.
• Good to know: The quorum arithmetic is small and worth having cold: with N=3 replicas, W=2 and R=2 overlap, so a read always touches the newest acknowledged write. Siblings are what you get for refusing to pick a winner. Eventually the client or a CRDT still has to.
• Spoke: /system-design/kv-store

27. Design a Leaderboard

• What it tests: Sorted sets until they shard, then top-k approximation.
• Who asks it: Gaming loops, another Xu chapter, three lists.
• The trap: Exact global rank for 100M players, in real time, because the PM asked. Nobody needs to know they're #41,932,806.
• The senior signal: Exact top-N, approximate everyone else; nobody below the fold ever checks.
• Good to know: A single Redis sorted set comfortably holds millions of members with log-time updates. One box goes further than people expect. Past that, shard by score range, keep the top 100 exact, and give the long tail percentile bands.
• Spoke: /system-design/leaderboard

28. Design a Unique ID Generator

• What it tests: A 64-bit layout you can defend, clock skew, per-node sequences.
• Who asks it: Rarely alone; it hides inside other questions the way bad clocks hide inside every distributed system. Three of the 11.
• The trap: "Just use UUIDs" when the requirement says sortable.
• The senior signal: An answer for the clock moving backwards.
• Good to know: Snowflake's split is 41 bits of milliseconds, 10 of node ID, 12 of sequence: about four million IDs per second per node for 69 years. When NTP steps the clock backwards, you stall or you burn sequence numbers. You never mint IDs from the past.
• Spoke: /system-design/id-generator

29. Design Object Storage (S3)

• What it tests: Blob placement, erasure coding vs. replication, a metadata layer that scales separately.
• Who asks it: Storage and infra teams. The last of the Xu chapters here.
• The trap: Putting metadata on the blob path.
• The senior signal: 6+3 erasure coding against 3x replication is roughly half the disk bill at the same durability. Put numbers on it and the room usually leans in.
• Good to know: The 6+3 scheme stores 1.5 bytes per byte versus 3.0 for triple replication. The price is CPU on writes and repair traffic when a disk dies. Buckets, keys, and versions are a database problem; the blobs themselves are a placement problem. Keep the two apart.
• Spoke: /system-design/object-storage

30. Design Tinder

• What it tests: Geo plus recommendations plus swipe-state at volume.
• Who asks it: Consumer-app loops. Two of the 11, and it still edges past three-list Zoom on a company tag. Judgment call, flagged.
• The trap: One service doing matching, geo, and ranking.
• The senior signal: Stream the swipes; a match is just an idempotent join.
• Good to know: Swipes are append-only events, and the match check is one indexed lookup: did the other side already swipe right. Geo shards by cell, recommendations precompute a daily deck per user, and none of those three want to live in the same service.
• Spoke: /system-design/tinder

Just missed: Zoom, Reddit, Spotify, email. Two or three catalogs each and zero company receipts in the window; Zoom's three lists losing to Tinder's tag is exactly the kind of call the rules force into the open. Reddit is the feed question again, and Pastebin merged into the URL shortener.

The Collapse: 30 Questions, 8 Patterns

Three evenings of tally marks bought exactly one insight worth the time: thirty questions reduce to eight patterns.

1. Tiny-payload lookup at silly read ratios (#1 URL shortener, #26 KV store, #28 ID generator). Hash it, store it, cache it, redirect.
2. Feed fan-out (#3 news feed, #12 Instagram). Push, pull, or hybrid; the celebrity always shows up.
3. Long-lived connections and ordering (#2 chat, #16 Docs). Sockets, sequence numbers, presence.
4. Media and blob pipelines (#4 video, #8 file sync, #29 object storage). Split the metadata from the bytes, then push the bytes to the edge.
5. Geospatial index and matching (#5 Uber, #11 Yelp, #17 Maps, #22 DoorDash, #30 Tinder). One geo index, five different jobs.
6. Contended inventory (#13 Ticketmaster, #15 payments, #23 exchange, #25 hotels). Somebody holds seat 14B, the hold expires, and nobody gets charged twice.
7. Streaming aggregation (#6 typeahead, #18 ad clicks, #19 metrics, #27 leaderboard). Count fast, approximate honestly, reconcile later.
8. Coordination primitives (#7 rate limiter, #9 crawler, #10 notifications, #14 cache, #20 scheduler, #21 queue, #24 LLM serving). Rate limits, queues, schedules. The crawler lives here because a frontier is a queue with manners; notifications because delivery is mostly queue discipline.

If I were starting my own prep again, I'd learn the eight and trust the thirty to compose themselves. DoorDash is five with six's inventory problem bolted on. ChatGPT serving is eight with GPUs attached.

And the three free weekends from the top? Eight patterns, two evenings each, change left over. That was the point of counting.

Company Skew: Who Asks What

The company-sourced data has a shape worth knowing.

Meta stays inside its own walls: feed, Instagram, WhatsApp, live comments, post search, typeahead. Google leans abstract on purpose, and its prompts (YouTube, Maps, autocomplete) arrive fuzzier than candidates expect. Amazon is the outlier: TinyURL, notifications, ticketing, food delivery, warehouse and cart internals. LLD creeps into Amazon loops.

Geo companies and fintechs are the most predictable pairs in the dataset. Uber wants geo all the way down; Stripe-shaped companies want payments and rate limiting until proven otherwise. OpenAI and Anthropic ask the newest class: ChatGPT, batched inference, LLM search. A staff loop I heard about this spring ran three design rounds, and two of them were LLM-serving variants.

And Microsoft mostly asks you to design other companies' products, which is its own kind of honest.

Startups: read the company's engineering blog the night before if you can. Half the time the question is their own architecture with the serial numbers filed off.

The Warning

Every list rots, including this one. Companies rotate question banks when they leak, prep sites re-rank when courses need selling, Glassdoor threads quietly die. This ranking is a snapshot with a date on it, June 2026, and it guarantees you nothing. It moves the odds, which is all counting has ever done.

The patterns rot slower. If I had to bet, that's where my money would go.

One more thing. Your interviewer is a tired human who probably asks whatever they were asked five years ago. That's the real reason the URL shortener will not die.

Thank you for reading. If you found this useful, followPracHubfor more practical deep dives on engineering, system design, and interview preparation written to help you build skills that last beyond a single article.

Sources

The twelve banks pulled, June 2026:

• PracHub, system design question bank (1,020 company-tagged questions at the June pull, checked again early July 2026; disclosure: it's where I do my own practice)
• roadmap.sh, top system design questions
• Educative, system design interview questions
• InterviewBit, system design questions (dropped: theory flashcards, no design prompts)
• Hello Interview, problem breakdowns (company and difficulty tags)
• IGotAnOffer, system design interviews (company-by-company Glassdoor data)
• Exponent, system design interview guide (partial: page too large to fully extract)
• DEV, top 50 system design questions
• ByteByteGo / Alex Xu, System Design Interview Vol. 1 & 2 (chapter lists)
• Design Gurus, Grokking the System Design Interview
• Medium (Soma), "50 system design interviews in 12 months" (partial: paywalled, no stable public link; search the title)
• Tech Interview Handbook, system design (updated April 2026)