If you've ever stared at a list of 200 system design interview questions and felt your motivation drain out through your shoes, this article is for you.
Here's the uncomfortable truth about preparing for system design interviews: most curated lists you'll find online are useless not because the problems are bad, but because they're presented as a flat soup. Designing TinyURL and designing a stock exchange are not the same kind of challenge. They don't take the same amount of preparation. They don't test the same skills. And lumping them together makes you feel like you have an impossibly long road ahead, when really the road is much shorter than it looks — you just need to walk it in the right order.
So I sat down with the four most respected system design courses on the internet — the original Grokking series, its Volume II successor, the advanced case-studies course, and the newer crash course — and pulled out every single design question. I ended up with 64 of them. Then I did something nobody else seems willing to do: I ranked them from easiest to hardest, in five clean tiers.
The result is a roadmap. Start at Tier 1, work your way up, stop when you hit the level your interview demands. No more drowning in a sea of equally-weighted problems. Let's go.
How to read this tier list
A few ground rules before you dive in.
Difficulty here means interview difficulty, not real-world difficulty. A problem like "design Amazon S3" is genuinely terrifying to build in real life, but as an interview question it's well-trodden territory and a strong candidate can navigate it with relatively few surprises. By contrast, "design a flash sale" sounds simple until your interviewer starts asking about fairness and you realize there are no easy answers. I've ranked by how hard the interview conversation tends to go, not by lines of code.
You don't need to finish every tier. If you're a junior engineer interviewing for a backend role, mastering Tiers 1 and 2 will get you a long way. Mid-level and senior candidates should be comfortable through Tier 3. Staff and principal candidates need Tier 4 in their bones, and Tier 5 — the real-world case studies — is where they go to win the room.
Repetition is intentional. A few problems appear twice across the four source courses (there are two YouTube questions, two Uber questions, two typeahead questions). I've kept all 64 because the alternate treatments often emphasize different angles, and reading both is genuinely educational.
With that out of the way, here are the 64 system design interview questions you should know in 2026, ranked.
Tier 1 — Warm-ups (8 questions)
These are the gentlest problems on the list. They typically focus on a single core idea — generating IDs, limiting throughput, building a simple lookup — and they're where every system design beginner should start. If you can't comfortably whiteboard these, no amount of advanced material will save you. Get fluent here first.
Design TinyURL
The first problem nearly everyone tackles. The whole exercise is about turning a long URL into a six-character code, but along the way you'll bump into hash collisions, base62 encoding, read amplification, and your first taste of when to introduce a cache. A perfect on-ramp.
Design Pastebin
A natural follow-up. Now your "value" is a multi-kilobyte text blob instead of a URL, which forces you to think about where blobs actually live (hint: not your relational database) and how to expire content gracefully without scanning the entire dataset.
Design an API rate limiter
Every backend engineer should be able to draw a token bucket from memory by the end of this one. The single-machine version is short and sweet — the perfect place to learn the algorithms before facing their distributed cousin.
Design a distributed rate limiter
Now imagine the same rate limiter, except enforced consistently across fifty edge servers in different regions. Suddenly the simple counter becomes a real distributed systems problem. This is your introduction to "consistency costs latency."
Design a unique ID generator
Why isn't auto-increment good enough? Spend twenty minutes on this question and you'll learn about Twitter's Snowflake, the role of clock skew, and why ordering identifiers by time is sometimes worth more than uniqueness alone.
Design typeahead suggestion
Your first encounter with the trie data structure in an interview context. The fun part isn't the trie — it's the constraint: you have under 100 milliseconds to return ranked suggestions, and your dictionary has tens of millions of entries.
Design typeahead/autocomplete
The crash course's modernized take on the same problem, with extra emphasis on personalization, fuzzy matching, and how trending queries get added to the suggestion pool in near-real-time. Worth doing both versions back-to-back.
Design an API gateway
The component everyone nods at and few can describe in detail. Authentication, throttling, request routing, and response transformation all live here. Designing one is the fastest way to understand what your microservice architecture is actually missing.
Tier 2 — The classics (15 questions)
This is the meat of the list — the system design interview questions that have been asked at FAANG companies for over a decade and remain in heavy rotation. If your interview is in two weeks, this is the tier where you should be spending most of your time. Every problem here exercises at least two non-trivial design dimensions, and most have a famous "right answer" that interviewers expect you to at least be aware of.
Design Twitter
The single most asked system design interview question, full stop. The conversation will inevitably arrive at the question of when to materialize a user's home timeline — at write time, at read time, or some hybrid — and your answer reveals more about your seniority than almost anything else you'll say.
Design Twitter timeline
A laser-focused version of the previous question that strips away everything except the timeline-generation problem. If you struggled with the broad version, this is the one to drill until your fan-out reasoning becomes second nature.
Design Instagram
Twitter, but the payload is photos and videos instead of text. That single change pulls in CDN strategy, image transformation pipelines, and a much more complicated story about storage tiers — hot, warm, and cold — than text-based systems require.
Design Facebook's newsfeed
Twitter, but ranked. The presence of a ranking layer changes everything: now you need a feature store, an ML serving layer, and a way to score thousands of candidate posts in milliseconds. A great problem to learn what production ML infrastructure actually looks like.
Design Reddit
Threaded comments are the technical highlight here, but the more interesting story is the time-decaying score function that powers Reddit's "hot" sort. Implementing it once gives you a tool you can apply to dozens of other ranking problems.
Design Facebook Messenger
A messaging system that has to handle billions of users, millions of concurrent connections, and the merciless requirement that messages arrive in order, without duplicates, and even when the recipient is offline. Long-polling vs. WebSockets is the appetizer; the main course is delivery semantics.
Design WhatsApp
Take Facebook Messenger and add end-to-end encryption, multi-device support, and the operational reality that most users are on bandwidth-constrained mobile networks. The cryptography rabbit hole is optional but rewarding.
Design Dropbox
The first problem on this list where the client matters as much as the server. Chunking, deduplication, delta sync, and conflict resolution turn a simple file upload service into a surprisingly intricate distributed systems problem.
Design Yelp or Nearby Friends
The geospatial indexing primer everyone needs at least once. Geohashes, quadtrees, and S2 cells all make appearances. Once you've internalized them, every other "find things near me" problem feels like a minor variation.
Design the Uber backend
Yelp's geospatial indexing meets a real-time matching engine. The dispatch algorithm — which driver gets which rider — is where most candidates either shine or stumble. Have a concrete answer ready.
Design Uber/Lyft
The crash course's updated treatment, with more attention to surge pricing economics, ETA prediction, and the subtle differences between batched and continuous matching. Read after the original Uber question for maximum effect.
Design a web crawler
The front-end of any search engine. The crawler itself is mostly a queue and a politeness budget — the hard parts are URL deduplication at scale, dealing with infinite URL spaces, and not getting your IPs banned from the entire internet.
Design Twitter search
The first system design interview question that forces you to confront inverted indexes. You'll learn how documents become postings lists, why sharding by term is harder than it sounds, and how to keep an index fresh when new documents arrive every millisecond.
Design Ticketmaster
The poster child for "strong consistency is expensive but sometimes necessary." Two people cannot buy the same seat. Period. Get this question wrong and you've burned a sold-out concert; get it right and you've demonstrated you understand distributed locking.
Design Google Calendar
Looks like a CRUD app, behaves like a logic puzzle. Recurring events, time zones, daylight saving time, and invitation propagation conspire to create one of the most underrated data modeling questions in the entire list.
Tier 3 — Modern systems (16 questions)
Tier 3 problems show up disproportionately in interviews at companies founded in the last decade or two. They tend to involve real-time collaboration, AI/ML, or operational concerns that older problems don't surface. If you're targeting modern infrastructure-heavy roles or AI-first companies, this is the tier that separates "competent" from "current."
Design Discord
Chat plus voice plus the unique pain of supporting servers with hundreds of thousands of members in a single channel. The naive fan-out approach explodes; the right answer involves hierarchical message distribution and very careful state management.
Design a live comment streaming service like Twitch chat
A million viewers, a few thousand chatters, and a chat that has to feel instantaneous. The trick is realizing that perfect delivery to every viewer is neither possible nor desirable — and architecting accordingly.
Design Google Docs
The system design interview question that introduces most engineers to operational transforms (or, more recently, CRDTs). Have at least a basic mental model of one of these algorithms before you sit down for this interview — bluffing is obvious.
Design a collaborative whiteboard like Miro
Google Docs, but the data model is a 2D plane of arbitrary objects and the latency budget is even tighter. The CRDT discussion gets weirder. The infrastructure discussion gets harder. A favorite at companies building real-time tools.
Design ChatGPT
The newest entry on the list and rising fast. The infrastructure conversation centers on GPU scheduling, KV cache reuse, streaming token responses, and conversational state management — none of which appear in any other interview question. Essential for AI infrastructure roles.
Design a notification system
Push, email, SMS, and in-app, all flowing through one pipeline. The interesting part isn't sending notifications — it's managing user preferences, channel-specific rate limits, and retries when downstream providers fail.
Design a Netflix-style recommendation system
A whirlwind tour of production ML: candidate generation, feature pipelines, batch model training, online serving, A/B testing infrastructure. Each piece is its own interview-worthy problem in disguise.
Design Gmail
Not just mailbox storage, but search-over-personal-data, threading, labels, spam filtering, and attachment handling. The variety of subsystems makes this a deceptively rich question.
Design Google News as a global aggregator
Crawling, deduplication, story clustering, and personalized ranking — all running continuously over a firehose of new articles. A great test of whether you can think in pipelines instead of in request-response.
Design a code judging system like LeetCode
Running untrusted code at scale is harder than it sounds. The architecture revolves around sandboxing, time and memory isolation, queue-based job dispatch, and aggressive result caching. A fun problem because every developer has used the system being designed.
Design a code deployment system
How do you ship code from a git push to a thousand production servers without anyone noticing? Blue-green deploys, canary releases, automated rollback triggers, and the orchestration layer that ties them together.
Design a metrics and monitoring system like Datadog
Time-series data has very different access patterns than general-purpose data, and the storage engines that handle it well — TSDB, columnar formats, hierarchical aggregation — are worth understanding even if you never build one yourself.
Design LinkedIn connections
Computing whether two users are connected through one, two, or three intermediate hops sounds easy. Doing it for a billion-user graph in under 100 milliseconds is one of the more elegant graph-precomputation problems on this list.
Design Facebook "People You May Know"
The graph problem with a recommendation twist. You're not just finding friends-of-friends — you're ranking them by signals that have little to do with the graph itself, which means an offline pipeline lurks behind the scenes.
Design Airbnb
A two-sided marketplace with search, availability calendars, reservations, payments, and reviews. Each subsystem could be its own interview, but the value of doing it as a single problem is learning how the pieces fit together.
Design a reminder alert system
Scheduling a billion future tasks efficiently is a problem nobody thinks about until they have to. The answer involves timing wheels, priority queues, and a careful consideration of what happens when a server hosting upcoming reminders crashes.
Tier 4 — Heavy hitters (18 questions)
Now we're in deep water. These are the system design interview questions that demand real depth — in distributed systems, in storage internals, in financial correctness, or in the economics of moving petabytes around. Senior and staff candidates should be able to handle these confidently. Junior candidates can absolutely study them, but don't beat yourself up if the conversations feel slippery on a first pass.
Design YouTube or Netflix
The original combined treatment of video streaming. Transcoding pipelines, adaptive bitrate streaming, and CDN economics dominate the conversation. This is where you learn that video is mostly a bandwidth problem dressed up as a software problem.
Design YouTube
A standalone, modernized YouTube design with extra weight on live streaming, viewer engagement metrics, and recommendation serving. Use this to deepen the parts the original glossed over.
Design Netflix
Pure focus on Netflix-specific challenges: the Open Connect appliance program, the microservices tangle that powers the product, and the chaos engineering ethos that keeps the whole thing running during a Friday night peak.
Design Google Search
Crawling, indexing, ranking, serving, and personalization — the whole stack behind the world's most-used query bar. Few candidates can do this question full justice in 45 minutes, but having attempted it gives you a framework for any search-related problem.
Design a distributed cache like Redis
Building a cache from scratch — sharding, replication, eviction, persistence, hot keys, and the nasty edge cases like cache stampedes. Mid-tier on the surface, but the conversation gets deep fast if your interviewer cares about durability.
Design a key-value store like DynamoDB
The cache's grown-up sibling, with full durability requirements. Quorum reads and writes, anti-entropy mechanisms, vector clocks, hinted handoff — all the concepts the Dynamo paper introduced and that every NoSQL store has had to grapple with since.
Design Amazon S3
The most durable storage system humans have ever built. Erasure coding, multi-region replication, the bucket-versus-key abstraction, and the strong-read-after-write semantics that make S3 such a reliable foundation for everything above it.
Design Amazon Lambda
Container pools, predictive warming, multi-tenant isolation, and the per-millisecond billing math that makes serverless economically viable. A surprisingly complex system hiding behind a simple programming model.
Design a distributed lock manager like Chubby
Coordination primitives for distributed systems, done right. Paxos or Raft, lease management, fencing tokens, and the corrosive realization that "implementing distributed locks with Redis" is full of bugs nobody warned you about.
Design a distributed job scheduler like cron
A cron daemon is trivial. A globally distributed cron that fires each scheduled job exactly once, even when machines die mid-execution, is one of the hardest exactly-once problems in the canon.
Design a payment system
Idempotency, double-entry bookkeeping, reconciliation, and the unforgiving truth that monetary correctness has zero tolerance for "eventually consistent." Get this right and you immediately sound like a senior engineer.
Design the Stripe payment gateway
The API-first cousin of the payment system question, with extra attention to webhooks, retries, idempotency keys, and the specific guarantees a payment processor offers to its merchants. Surprisingly hard if you've never thought about it.
Design Amazon shopping cart
The original use case for Amazon Dynamo. The interesting question isn't how to store items in a cart — it's how to merge two carts that diverged on different devices, and why the answer involves accepting eventual consistency.
Design a flash sale for an e-commerce site
Inventory of 100 items. A million users hitting "buy" at the same instant. How do you protect the database, allocate items fairly, handle the inevitable losers gracefully, and not crash the entire site? One of the most operationally interesting questions on the list.
Design Google Ads
Real-time auctions, bid optimization, budget pacing, click tracking, and ad fraud detection. Easily the largest "design X" problem on this list by surface area, and the one most candidates underprepare for.
Design an ad click aggregator
A focused drill on the click-counting and deduplication piece of an ad system. Pure stream-processing territory, with all the exactly-once and late-arriving-data fun that implies.
Design a stock exchange
Microsecond latency, deterministic ordering, and a regulator looking over your shoulder. The matching engine is the centerpiece, and even thinking about it for an hour will recalibrate your sense of what "fast" means in software.
Design a YouTube likes counter
A whole question about counting. Sounds dumb until you try to count millions of likes per second on a single video without losing data and without creating a single hot row that takes down your database. The answer is sharded counters, and it's beautiful.
Tier 5 — Real-world case studies (7 papers)
The final tier is different from everything above it. These aren't open-ended "design X" questions — they're guided tours through real, production-scale systems whose papers and source code shaped modern infrastructure. At staff and principal interviews, an interviewer might casually ask, "How does Cassandra handle replication?" or "Why did Kafka choose a log-based design?" These case studies prepare you for exactly those moments.
Treat them like papers, not like problems. Read slowly. Take notes. Come back to them.
Amazon Dynamo
The paper that launched the NoSQL era. Consistent hashing, vector clocks, sloppy quorums, and Merkle-tree anti-entropy — every modern key-value store traces its lineage back to the ideas in this paper.
Apache Cassandra
Dynamo's open-source descendant, reimagined with a wide-column data model and an LSM-tree storage engine. The case study walks you through gossip-based cluster management, tunable consistency, and the compaction process that keeps everything tidy.
Apache Kafka
The distributed log that became the spine of every modern event-driven architecture. Understand partitions, consumer groups, leader election, and the precise meaning of each delivery semantic — at-most-once, at-least-once, and the elusive exactly-once.
Google Chubby
The original distributed lock service that inspired ZooKeeper, etcd, and every coordination system built since. The most valuable lesson here isn't the Paxos implementation — it's the design philosophy behind preferring coarse-grained locking to fine-grained.
Google File System
A 2003 paper that made everyone reconsider what a filesystem had to be. Single master, 64MB chunks, weak consistency, optimization for append-heavy workloads — every design choice in GFS is a teaching moment.
Hadoop Distributed File System
The open-source response to GFS. The interesting exercise is comparing the two side by side and noticing where the open-source community made different trade-offs than Google's internal team — and why.
Google BigTable
The wide-column data model that influenced HBase, Cassandra, and the entire wave of column-family databases that followed. Beyond the data model, BigTable is a stunning example of system composition: it's built on top of GFS for storage and Chubby for coordination, and the architecture only makes sense when you understand both.
A final word: study tier by tier, not problem by problem
Here's my advice if you do nothing else with this list:
Pick one problem from each tier you need to master. Whiteboard it from scratch — no notes, no peeking. Then read the linked solution. Compare your design to theirs. Note every place you missed something, and write the missed concept on a separate sheet. That sheet, after a dozen problems, becomes your personal study guide. It's better than any list a stranger on the internet can give you, because it tells you exactly where your gaps are.
Repeat the process. Move up the tiers. By the time you've worked through 15 to 20 of the 64 system design interview questions on this list, you'll notice something strange: the new ones start to feel familiar before you even read the prompt. That's not memorization. That's the patterns clicking into place.
And when the patterns click, the interview stops being scary. It becomes a conversation — one where you're the person with the toolbox, calmly picking the right tool for the problem in front of you.
That's the goal. Good luck out there.
Top comments (0)