The only system design interview questions reading list you need
A pattern-based reading list to replace the overwhelm of system design prep.
I get the same question in my DMs almost every week: “Which system design interview questions should I actually practice?”
It’s a fair question, and it’s harder to answer than it sounds. If you spend ten minutes on Reddit or LeetCode discuss, you will find people swearing by wildly different lists. Some say you only need five classics. Some post sprawling spreadsheets with two hundred problems. Meanwhile you have an onsite in three weeks and you don’t know where to start.
Here is my honest take, after years of watching candidates succeed and fail at these interviews: the set of system design interview questions that actually get asked at top tech companies is smaller than you think, and the set worth deeply understanding is smaller still. What matters is not how many problems you have touched, but how many patterns you have internalized. Once you see the pattern behind “design a news feed,” you also see it behind “design Reddit,” “design LinkedIn connections,” and half a dozen other variants.
So instead of handing you a flat list of 64 problems in random order, I have organized this reading list by the patterns they exercise. Work through one or two problems from each group and you will walk into your interview with a genuine mental toolbox, not a pile of memorized answers. Every question below links to a detailed walkthrough from Design Gurus — the most complete catalog of system design interview questions I have found online.
Let’s get into it.
Why pattern-based study beats problem-based study
Before the list, a quick defense of this approach, because it matters.
If you study system design interview questions one by one, you end up learning 64 things. If you study them by pattern, you end up learning maybe 15 things — and then you can recombine them to answer anything. The interviewer who asks you to design a Twitch chat is not testing whether you have memorized Twitch chat. They are testing whether you can reason about pub/sub fan-out, backpressure, and message ordering in a room with a million passive listeners and a few thousand active speakers. If you understand those three patterns, you can design Twitch chat, Discord channels, live sports commentary, and a dozen other things you have never seen before.
The same logic applies to storage, caching, ranking, scheduling, consistency, and every other major topic. Pattern first, problem second. With that established, here is the list.
Pattern 1: Core infrastructure primitives
Almost every complex system is built on a small number of primitives: identifiers, keys, queues, caches, locks, schedulers. If you cannot design these from scratch, you will stumble when a larger problem asks you to bolt one onto your architecture. Start here.
Design a URL shortening service like TinyURL
The obvious first problem, and for good reason. It is the simplest thing in the world on the surface — turn long URLs into short ones — and yet it quietly forces you to reason about key generation, collision avoidance, read-write ratios, and database sharding. A rite of passage.
Design Pastebin
A sibling of TinyURL, but with blob storage, expirations, and analytics layered on top. Good for learning when your metadata lives in a database and your payload lives somewhere cheaper.
Design an API rate limiter
You will be asked to add rate limiting to almost every other system you design in an interview loop. Understand the classic algorithms — token bucket, leaky bucket, sliding window counter — and why the naive implementation does not survive a distributed environment.
Design a distributed rate limiter
The grown-up version of the above. Once you have more than one server enforcing limits, you either need shared state (expensive) or probabilistic agreement (clever). This question is where you learn the difference.
Design a unique ID generator
Why can’t you just use an auto-increment column? Walk through the answer and you end up in Snowflake-land, thinking about clocks, machine IDs, and why ordering matters more than you expected.
Design a distributed cache like Redis
Caches are the duct tape of system design. Build one from scratch and you suddenly understand why every senior engineer has opinions about LRU, write-through, cache stampedes, and hot keys.
Design a key-value store like DynamoDB
The durable cousin of the cache. This is where you meet quorum writes, anti-entropy, and the consistency trade-offs that define most modern NoSQL systems.
Design an API gateway
Once you have more than a handful of microservices, something has to sit in front of them. Learn what that something actually does — auth, throttling, routing, request shaping — and why it is almost never stateless in practice.
Design Amazon Lambda
Serverless is one of those topics that sounds magical until you ask “but how?” The answer involves container pools, predictive pre-warming, and a surprising amount of scheduling math.
Design a distributed job scheduler like cron
A cron that runs on one machine is trivial. A cron that runs on a thousand machines and must not miss or double-fire any job is a genuinely hard distributed systems problem. This is where you learn about leases, fencing tokens, and idempotent execution.
Design a distributed lock manager like Chubby
If the job scheduler teaches you why distributed coordination is hard, this one teaches you how people solve it. Paxos, Raft, leases, and the subtle bugs that eat engineers who try to implement locking with just Redis.
Design a code deployment system
How does code get from a git commit to a thousand production servers without anyone noticing? Blue-green, canaries, rolling updates, health checks, automatic rollback — a quietly rich problem.
Design a metrics and monitoring system like Datadog
Time-series data has very different properties from general-purpose data, and the systems that store it make very different trade-offs. Worth building once just to understand what makes Prometheus, InfluxDB, and friends tick.
Design a reminder alert system
Surprisingly subtle. How do you efficiently wake up a billion pending reminders at their scheduled times without scanning a billion rows every second? Hello, timing wheels.
Pattern 2: Social feeds and ranking
The second-most-asked category, probably. If you are interviewing at a company whose main product involves users consuming content from other users, you will get one of these.
Design Twitter
The canonical feed problem. The whole interview hinges on one question — do you generate the timeline when a tweet is posted, or when a user opens the app? — and the answer is “it depends, and here is how I would decide.”
Design Twitter timeline
A focused drill on just the timeline generation problem. If you struggled with the fan-out question above, come here for the deeper version.
Design Instagram
Twitter with photos. The photos part matters more than it seems, because it pushes you into CDN strategy, image processing pipelines, and cheap-versus-hot storage decisions.
Design Facebook’s newsfeed
Twitter with ranking. Unlike Twitter, Facebook aggressively reorders your feed, which means you now need a ranking service, feature computation, and a way to serve ML models at feed-generation time.
Design Reddit
Threaded comments and time-decaying scores are the interesting parts here. The classic Reddit “hot” ranking is worth writing out by hand once — it is a small but delightful piece of math.
Design Twitter search
Full-text search over a stream of brief documents arriving at firehose speeds. This is your gentle introduction to inverted indexes, sharding by term, and near-real-time indexing.
Design Facebook “People You May Know”
Graph traversal at a billion-user scale, with the added twist that the results are ranked by signals that have nothing to do with the graph structure. A good excuse to talk about offline computation pipelines.
Design LinkedIn connections
“How many hops away is this person from me?” is cheap on a small graph and catastrophic on a social network. Come for the breadth-first search, stay for the precomputation strategies.
Design Facebook Messenger
Chat and feeds overlap more than you would think. The question is less “how do you send a message?” and more “how do you guarantee ordering, presence, and delivery across unreliable networks and offline clients?”
Pattern 3: Real-time and collaborative systems
These problems share a common shape: many clients, low-latency updates, nontrivial consistency. They are the hardest category, in my opinion, because the consistency discussion gets very real very quickly.
Design WhatsApp
Like Messenger, but with end-to-end encryption, multi-device key management, and the fact that most of your users are on flaky 3G connections in countries with weather.
Design Discord
Chat, voice, presence, and massive rooms. A single Discord server can have hundreds of thousands of members, which breaks naive fan-out models the moment you try them.
Design a notification system
Push, email, SMS, in-app — all different channels with different delivery semantics, different failure modes, and different rate limits. The challenge is building one system that handles all of them gracefully.
Design a live comment streaming service like Twitch chat
A million passive readers, a few thousand active writers, and a chat that must feel instant. The answer involves hierarchical fan-out, lossy delivery, and the uncomfortable realization that perfect consistency is neither possible nor desired here.
Design Google Docs
Collaborative editing is the problem that made operational transforms famous (and CRDTs later). If you have never read about either, be prepared for the most interesting algorithm discussion of your interview prep.
Design a collaborative whiteboard like Miro
Google Docs with a canvas instead of text. The CRDTs get weirder when your data model is a spatial set of objects, and the pressure to minimize latency gets more intense.
Design typeahead suggestion
A classic trie problem with a real-time update twist. You are allowed maybe 100 milliseconds end to end, which changes how you think about every layer.
Design typeahead/autocomplete
The modernized version, with more focus on personalization and handling misspellings. Good to do after the classic version so you can see what changes at scale.
Pattern 4: Media, streaming, and discovery
Large files, global audiences, ranked recommendations. This category is less about consistency and more about the economics of moving bytes.
Design YouTube or Netflix
Your crash course in transcoding pipelines, adaptive bitrate streaming, and CDNs. Also your first encounter with the uncomfortable truth that video is mostly a storage and bandwidth problem, not a computation one.
Design YouTube
A modern take on the above, with more emphasis on live streaming and recommendation serving. The infrastructure requirements for live video are dramatically different from on-demand, which is worth discussing even briefly.
Design Netflix
This time you get to talk about Open Connect (Netflix’s home-grown CDN) and the operational discipline that makes a streaming service robust. Chaos engineering makes a cameo.
Design a Netflix-style recommendation system
Where offline ML meets online serving. You will end up sketching a feature store, a model server, and an ETL pipeline whether you meant to or not.
Design Dropbox
File sync across clients is secretly a distributed systems problem wearing a user-friendly disguise. Chunking, deduplication, and conflict resolution do most of the work.
Design Gmail
Email at hyperscale: attachment storage, search, labels, threading, and spam filtering are each small services that happen to compose into a product people have used for twenty years.
Design Google News as a global aggregator
Continuous crawling, story clustering, deduplication, and personalized ranking in a single pipeline. A great problem for anyone who wants practice thinking in streams rather than in requests.
Design a web crawler
The front end of a search engine. Frontier management, politeness policies, and how to avoid crashing your own infrastructure when you accidentally point your crawler at a badly written site.
Design Google Search
The full stack behind the world’s most famous query bar. Ambitious for a 45-minute interview, but having thought about it end-to-end gives you a framework for any search problem.
Pattern 5: Location, marketplaces, and booking
These share a geography problem and an inventory problem. Both are harder than they look.
Design Yelp or Nearby Friends
Geospatial indexing, in depth. Once you have seen geohashes, quadtrees, and S2 cells, a surprising number of “location-aware” interview questions reduce to variations on the same theme.
Design the Uber backend
Yelp plus matching plus real-time tracking plus pricing. The dispatch algorithm is the piece most candidates underweight, and it is often what your interviewer wants to hear about.
Design Uber or Lyft
A refresher on the above with a modern lens — surge pricing dynamics, ETA prediction, and the subtle economic mechanisms that keep supply and demand balanced.
Design Airbnb
A two-sided marketplace with search, availability calendars, booking, and reviews. Each of those is its own little subsystem with its own consistency needs.
Design Ticketmaster
Strong consistency, distributed locking, and the emotional reality that your users are actively trying to beat each other to the same seat. Rare as a real-world problem, beloved as an interview problem.
Design Google Calendar
You would think this one would be easy. It is not. Recurrences, time zones, invitation semantics, and calendar sharing conspire to create a genuinely tricky data model.
Pattern 6: Money, inventory, and accounting
The highest-stakes category, because the margin for error is zero.
Design a payment system
Double-entry bookkeeping, idempotency, and the hard lesson that “exactly once” is a goal you approximate rather than achieve. If you get this one right, you sound senior.
Design the Stripe payment gateway
A more concrete, API-first version of the payment system problem. The conversation inevitably turns to webhook reliability, which is a whole topic unto itself.
Design Amazon shopping cart
The original motivating use case for Dynamo. You learn why Amazon chose availability over consistency and why the merge-carts-on-login flow looks the way it does.
Design a flash sale for an e-commerce site
The purest possible form of the thundering-herd problem. A good excuse to talk about pre-reservation queues, fairness, and graceful degradation.
Design Google Ads
Auctions, bidding, budget pacing, click tracking, and fraud detection. Probably the hardest “design X” question if you are unfamiliar with how ad tech works.
Design an ad click aggregator
A focused drill on the counting-and-deduplication piece of Google Ads. You end up in stream-processing land fast, which makes it a great companion problem.
Design a stock exchange
Microsecond latency, strict ordering, and regulatory paper trails. The matching engine is the centerpiece, and thinking about it briefly will change how you reason about throughput ceilings forever.
Design a YouTube likes counter
Counting at scale is harder than you think. The whole question is about how to distribute a hot counter across shards without losing accuracy or blowing up latency.
Pattern 7: Storage, files, and very large data
Object stores, file systems, and the architectures that hold the internet’s bytes.
Design Amazon S3
Eleven nines of durability does not happen by accident. Erasure coding, geographic replication, and eventual-consistency-with-strong-read-after-write are the magic ingredients.
Design a code judging system like LeetCode
The interesting part is sandboxed execution — how do you safely run arbitrary code from strangers without losing your entire compute fleet? The queueing and result caching are almost an afterthought.
Design ChatGPT
The newest problem on the list and, increasingly, the most asked one. GPU scheduling, KV cache management, streaming token responses, and the surprisingly tricky question of where conversation state lives.
Pattern 8: Real-world case studies you should read like papers
This last group is different. These are not “design X” questions where you draw boxes on a whiteboard. They are deep dives into real, shipped systems whose design decisions every senior engineer should be familiar with. At staff and principal level, interviewers will casually ask you how Kafka achieves durability or why Cassandra uses gossip. These case studies prepare you for those moments.
Read them slowly. Take notes. Come back a week later and re-read them.
Amazon Dynamo
The paper that kicked off the NoSQL movement. Every modern distributed key-value store owes something to Dynamo, whether it admits it or not.
Apache Cassandra
Dynamo’s ideas, reimplemented open-source with a different data model and LSM-tree storage. A tour of gossip, tunable consistency, and the compaction engine that keeps everything honest.
Apache Kafka
The distributed log that quietly ate the world. Understand why it is log-structured, what a partition really is, and what the various delivery semantics actually cost.
Google Chubby
Before ZooKeeper and etcd, there was Chubby. Reading about it is the fastest way to understand what a lock service is actually for, and why coarse-grained locking tends to win over fine-grained.
Google File System
The paper that taught a generation of engineers to question their assumptions about what a filesystem had to be. Single master, 64MB chunks, and a weak consistency model that somehow worked.
Hadoop Distributed File System
The open-source response to GFS. Comparing the two side by side is one of the most educational exercises in distributed systems.
Google BigTable
The wide-column data model that influenced HBase, Cassandra, and every table-ish thing in modern infrastructure. Bonus: it is a beautiful example of a system built by composing other systems (GFS plus Chubby).
A short plan of attack
If you have three weeks, here is what I would do with this list:
Week one, spend your time on Pattern 1 (infrastructure primitives) and pick two problems from Pattern 2 (social feeds). The primitives are reusable, and one or two feed problems will build your instinct for fan-out. Do not try to memorize answers. Draw the diagrams from scratch every time and explain your decisions out loud.
Week two, mix in Pattern 3 (real-time), Pattern 4 (media), and one problem from Pattern 6 (money). These expose you to the hardest consistency discussions and the hardest “many clients, low latency” discussions — the two places interviewers love to probe.
Week three, read through Pattern 8 (real-world case studies) slowly. You will not build anything, but you will absorb vocabulary, references, and mental models that make everything else in your prep click into place. End the week by doing two full mock interviews from problems you have not studied, just to prove to yourself that you can handle the unfamiliar ones.
That is it. That is the whole plan. The myth of system design interviews is that you need to know 200 problems cold. The reality is that you need to know maybe 15 well and be able to reason from first principles about the other 185. This list is the shortest path I know to get there.
If you found this useful, forward it to the friend in your group chat who keeps asking what to practice. And good luck with your interview loop — you are going to do better than you think.