System Design Interview Questions: What Repeats

System design interview questions fall into three groups once you stop treating them as a random archive: core concepts you need before you can discuss anything else, infrastructure-building questions that repeat across almost every company, and product-feature questions tied to what the company you're interviewing at actually builds. Companies vary less than most candidates expect. They pull from the same small set of primitives and combine them differently depending on their product. This guide groups the questions you're actually likely to face, explains what each one is really testing, and links to full walkthroughs for the ones we've built out in our own question bank, instead of leaving you with a bare list of names and no explanation.

What Do System Design Interview Questions Actually Test?

A system design interview question tests whether you can turn a vague, underspecified prompt into a working architecture under real constraints, not whether you've memorized the exact system a specific company actually runs in production. The interviewer already knows there's no single correct answer to "design a URL shortener" or "design a chat system". What they're grading is the process: do you ask clarifying questions before you start drawing boxes, do you estimate scale before you pick a database, and can you defend a tradeoff out loud when it gets pushed on.

That's why the same handful of questions get reused across companies with completely different products. A rate limiter tests the same reasoning at a payments company, a social app, and a developer tools startup, even though the actual traffic patterns each one deals with look nothing alike. Once you see a question as a test of a specific reasoning skill rather than a specific answer, the prep changes. You stop trying to memorize forty architectures and start practicing the handful of tradeoffs that show up in almost all of them: consistency versus availability, read-heavy versus write-heavy access patterns, and where a cache actually helps versus where it just adds a stale-data problem you now have to manage.

Our 45-minute framework covers the actual timeline you run against any question on this list: requirements, estimation, high-level design, a deep dive, and a wrap-up. Treat the questions below as the raw material and that framework as the process you apply to each one.

Which Core Concept Questions Come Up Before Any Real Design?

Before a company hands you a full system to design, most interviewers check whether you know the underlying vocabulary well enough to use it correctly under pressure. These rarely get asked as standalone questions past an early screen, but they surface constantly as follow-ups once you've picked a database or drawn a cache into your diagram.

• CAP theorem: consistency, availability, and partition tolerance, and why a distributed system can only guarantee two at once during a network partition.
• Horizontal versus vertical scaling: adding more machines instead of a bigger one, and why horizontal scaling is the default past a certain size.
• Caching and invalidation: where a cache sits in the request path and what breaks when the data behind it changes.
• Sharding and partitioning: splitting data across machines by a key, and what happens when that key gets chosen badly.
• SQL versus NoSQL: when a relational schema and joins genuinely help, and when a document or key-value store fits the access pattern better.

Interviewers ask these because a candidate who can't explain why sharding by user ID can create a hot shard for a popular account usually can't be trusted to make that call correctly during the deep-dive portion of a bigger design either. Get comfortable defending each one with a real example, not just a definition, before you move on to full systems.

Which Infrastructure Questions Show Up in Almost Every Loop?

A small set of infrastructure questions repeats across nearly every company's system design loop, regardless of what the company actually sells: design a URL shortener, design a rate limiter, design a web crawler, design a notification or messaging queue, design a distributed file storage system like Google Drive or Dropbox, and design a typeahead or autocomplete search box.

These repeat because each one isolates a single primitive cleanly enough to grade in forty five minutes. A URL shortener is really a test of hashing and redirect design, plus how you handle collisions at scale. A rate limiter is a test of the token bucket or sliding window algorithm and where you enforce it in a distributed system with multiple servers. A web crawler is a test of breadth first traversal combined with politeness constraints so you don't hammer one domain. A notification system tests whether you understand publish-subscribe and how to fan a single event out to millions of subscribers without a single point of failure.

Distributed file storage and typeahead search test two more primitives that don't show up in the questions above. A Drive or Dropbox style design tests how you break a large file into chunks, store the chunks across multiple machines, and keep a separate metadata service that tracks which chunks belong to which file so a client can reassemble it correctly even after a sync conflict. A typeahead or autocomplete design tests a completely different skill: building a trie or a similar prefix structure that returns ranked suggestions in single-digit milliseconds, and deciding how often that structure gets rebuilt as new search terms become popular. Neither one overlaps much with the other four, which is exactly why interviewers keep reaching for all six instead of settling on just one or two favorites.

We have a full worked walkthrough of designing a URL shortener and a separate one for designing a rate limiter, both pulled from real onsite reports rather than written from a textbook description. If a prompt matches one of the six above, work through the walkthrough end to end instead of reading a summary, since the follow-up questions in a real loop usually target the exact detail a summary skips.

Which Product-Feature Questions Come Up Most?

Product-feature questions ask you to design a version of something the interviewer's own company, or a company like it, actually ships: a chat system like Slack or WhatsApp, a news feed like Facebook or Instagram, a ride-matching system like Uber or Lyft, a video platform like YouTube or Netflix, and a search-and-recommendation system for a marketplace.

These test a different skill than the infrastructure questions above. A chat system question is really about fan-out: whether a message gets pushed to every online participant in real time or pulled on demand, and how you handle a user who's offline when the message arrives. A news feed question is about ranking and the tradeoff between computing a feed ahead of time for every user versus assembling it on read. A ride-matching question is about geospatial indexing, matching a rider to a nearby driver fast enough that neither one waits, and handling the surge in demand during a concert letting out or bad weather. If a prompt says "design something like Slack" or "design a chat system", name the fan-out decision explicitly in your first few minutes, since it's the one choice the rest of the design hangs on.

A video platform design tests a pipeline you won't see anywhere else on this list: how an uploaded file gets transcoded into several resolutions, stored, and served through a content delivery network close enough to the viewer that playback doesn't stall. A marketplace search-and-recommendation question, closer to what Airbnb or Amazon actually run, tests whether you can combine a search index with a separate ranking layer, and whether you know why those two usually live in different services instead of one. Both questions reward the same habit as the chat and feed questions: naming the one hard tradeoff early instead of drawing a generic three-tier diagram and hoping the interviewer doesn't ask why.

What Mistakes Cost the Most Points in a System Design Round?

The single most common mistake is skipping requirements and estimation to start drawing boxes immediately, because it feels like progress. An interviewer who watches a candidate design a full chat system without ever asking how many users it needs to support, or whether messages need to survive a server restart, has already learned the most important thing about that candidate before the whiteboard fills up. Spend the first five minutes asking questions even when the prompt feels familiar, since the constraints an interviewer cares about that day rarely match the constraints in the version of the question you practiced.

A second mistake is picking a single component and going deep on it without checking whether that's actually where the interviewer wants the time spent. A candidate who spends fifteen minutes on database schema design for a rate limiter question, when the interviewer was hoping to discuss distributed enforcement across multiple servers, has used the clock on the wrong thing. Ask directly which part the interviewer wants you to go deeper on once you've sketched the high-level design, instead of guessing.

A third mistake is presenting a design with no acknowledged weaknesses, as if the first architecture you thought of has no tradeoffs at all. Every real design has a weak point: a single point of failure you haven't addressed yet, a cache that can serve stale data for a few seconds, a shard key that could get hot under an unusual traffic pattern. Naming that weakness yourself, before the interviewer has to ask, reads as more senior than a design that looks perfect until the first follow-up question exposes the gap.

Do Different Companies Ask Different System Design Questions?

The underlying primitives stay the same everywhere, but which ones get emphasized shifts with what the company actually builds. A payments or fintech company leans harder on consistency, idempotency, and exactly-once processing, since a duplicate charge is a real production incident rather than a theoretical edge case. A social or content company leans harder on fan-out and ranking, the same two ideas behind the chat and feed questions above. A marketplace or logistics company, closer to Uber, DoorDash, or Airbnb, leans on geo-matching and handling real-time state for things that move. An infrastructure or developer-tools company leans on API design and the scaling primitives from the core concepts section, since that's closer to what they actually build day to day.

That pattern is a better prep strategy than trying to guess a specific company's actual interview format, which changes over time and varies by team even inside the same company. Our company pages compile the specific questions candidates have reported from real loops, grouped by company, so you can check what's actually been asked at your target company instead of guessing from a generic list built around no company in particular.

How Many of These Should You Actually Practice?

You don't need to design forty systems from scratch to walk into a system design round prepared. Working through five or six, one from each category above, chosen deliberately instead of copied from a list you half memorized, builds more real skill than grinding through every question a company has ever reportedly asked.

Pick one infrastructure question and go deep enough to defend every design decision under a follow-up, pick one product-feature question and practice naming the core tradeoff in the first two minutes, and make sure you can explain the core concepts section well enough to use them correctly inside whichever design you land on. That combination covers most of what actually shows up, and it leaves you with real reasoning you can adapt live instead of a memorized answer that falls apart the moment the interviewer changes one constraint. The value of a curated set over an unfiltered archive is exactly this: fewer questions, chosen because they still show up in current loops, worked through completely instead of skimmed.

Practicing this way also changes how you use your remaining prep time. Once you've internalized why a rate limiter enforces its limit at the load balancer layer rather than inside each individual server, that same reasoning about shared state across distributed instances carries directly into a notification system, a chat system, or almost any other design you haven't specifically rehearsed. The goal isn't coverage of every possible prompt a company might use. It's building a small set of transferable answers to the handful of questions that actually decide whether a distributed system holds up under load, so you can reason your way through whatever specific version shows up on interview day instead of hunting for a prompt that matches something you memorized.

Frequently Asked Questions

What are the most common system design interview questions?

The most common ones split into infrastructure questions, like designing a URL shortener, a rate limiter, a web crawler, or a notification system, and product-feature questions, like designing a chat system, a news feed, or a ride-matching platform. Almost every company's system design loop draws from this same short list, combined with a handful of core concept questions like the CAP theorem or cache invalidation used as follow-ups.

How many system design interview questions should I practice before interviewing?

Five or six worked all the way through, one from each major category, teaches more than dozens skimmed at a summary level. Pick at least one infrastructure question and one product-feature question, work each one to the point where you can defend every decision under a follow-up, and make sure the core concepts behind both are second nature.

Do system design interview questions differ between companies?

The underlying primitives stay consistent everywhere, but the emphasis shifts with what the company builds. A payments company tests consistency and idempotency harder, a social company tests fan-out and ranking harder, and a marketplace tests geo-matching and real-time state harder, even though all three might ask a version of the same base question.

What's the difference between infrastructure questions and product design questions?

An infrastructure question, like a rate limiter or a URL shortener, isolates one technical primitive cleanly enough to grade on its own. A product design question, like a chat system or a news feed, combines several primitives at once and tests whether you can prioritize which tradeoff matters most for that specific product under real time pressure.

How long does a system design interview question actually take?

Most system design rounds run 45 to 60 minutes for a single question, split roughly between clarifying requirements, estimating scale, sketching the high-level design, and going deep on one or two components the interviewer picks. Our system design framework breaks that timeline down minute by minute.

Do I need to know a specific company's real production architecture to answer these questions well?

No, and claiming inside knowledge of a real production system you've never worked on usually backfires if the interviewer pushes on a detail. Interviewers grade your reasoning against the constraints they give you in the room, not against the actual system running in production, so a well-defended, self-consistent design beats a guess at internals you can't actually verify.