System Design Interview Questions: What's Graded
By Rostyslav Myronenko, holder of 14 active AWS certifications.
, updated . 11 min read
Most lists of system design interview questions give you the prompts and a reference architecture for each one. That's useful for the first week. The prompts repeat, so after a while you know them all, and what decides the loop is what the interviewer writes down while you talk.
Below are twelve prompts that keep coming up in published question banks, the signal each one mostly grades, and the sentence candidates tend to skip. Cloud and solutions architect roles add an AWS scenario round, which has its own post. The prompts are the widely published ones. Nothing here comes from any company's actual interview loop.
In fourteen years of interviewing engineers, the result I see most often is a correct architecture with a mixed score. The boxes are right and the arrows are right, but one signal never came up, so the interviewer has nothing to write in that row.
What a system design interview grades
I score a mock on five signals. Other rubrics use different names and sometimes add a row, but they cover much the same ground.
- Requirements. You pin down what the system has to do, for whom and at what scale before you draw anything, including the non-functional side: latency, availability, consistency, retention.
- Data model. You name the entities and the access patterns, choose keys, and pick storage that fits the queries you'll actually run.
- Scaling story. You put numbers on the design (requests per second, storage per year, read-to-write ratio) and say what breaks first as they grow.
- Trade-offs. You name the option you didn't pick and why: push or pull, SQL or NoSQL, consistency or availability, cache or no cache.
- Communication. You drive the conversation, check in with the interviewer, keep to time and make your reasoning visible.
These are the five rows on the scorecard I send after a coaching mock. A strong answer shows all five. One empty row is often enough to turn a hire into a no-hire, which is why learning more architectures helps less than people expect.
12 common system design interview questions
Communication is graded in all twelve, so it's listed as the main signal only where the prompt is broad enough to test it on its own.
1. Design a URL shortener
It mostly grades the data model. The prompt looks trivial on purpose. The interviewer wants to see how you generate short keys (hash, counter or pre-generated pool), how you avoid collisions, and how you store a mapping that's read far more often than it's written. Redirect caching and the choice between a 301 and a 302 come up if analytics matter.
When I run this one, people usually go straight to hash functions before anyone has asked how many links a day we're shortening.
The sentence candidates skip: "I'll hand out key ranges from a counter to each server, so no two servers issue the same key and I never need a collision check."
2. Design a rate limiter
It mostly grades trade-offs. Token bucket, leaky bucket, fixed window and sliding window all work, and each costs something different: how it handles bursts, how much memory it needs per client, how accurate it is at the edge of a window. Say which cost you accept for this system. Then come placement (client library, API gateway or sidecar) and shared state, usually in an in-memory store across instances.
Candidates tend to know the four algorithms well. They go quiet when I ask what happens if the limiter itself fails.
The sentence candidates skip: "If the counter store goes down, do we fail open and let traffic through, or fail closed and reject it?"
3. Design a news feed
It mostly grades the scaling story. Fan-out on write makes reads cheap and writes expensive. Fan-out on read does the opposite. Most real designs end up hybrid, and the interviewer wants to hear why.
The sentence candidates skip: "What happens when an account with ten million followers posts?"
4. Design a chat application
It mostly grades requirements. One-to-one and group chat, delivery receipts, online presence, message history and push to offline devices can each be a whole interview. Candidates who start drawing WebSocket servers before scoping end up designing everything at once and nothing in depth.
The sentence candidates skip: "Do messages have to arrive in order, and is that per conversation or across all of them?"
5. Design a notification system
It mostly grades communication. Push, email, SMS and in-app notifications, user preferences, retries, deduplication and per-user limits add up to more than 45 minutes of work. The interviewer watches whether you scope it out loud and hold to the plan.
The usual failure in a mock is trying to cover every channel and reaching the last five minutes with retries and deduplication still undrawn.
The sentence candidates skip: "There are four channels here. I'll design push end to end and then tell you where email and SMS differ."
6. Design file storage and sync
It mostly grades the data model. Think of Dropbox or Google Drive: the design turns on splitting files into chunks, addressing each chunk by its content hash, and keeping file metadata apart from file bytes. Sync then becomes a question of which chunks changed.
The sentence candidates skip: "Chunks are addressed by hash, so an edit uploads only the changed chunks and identical chunks are stored once."
7. Design ride matching
It mostly grades the scaling story. Drivers send their location every few seconds, so this is a write-heavy system before anyone books a ride. Geospatial indexing (geohashes, quadtrees or hexagonal grids) and partitioning by region follow from that number.
People often pick a quadtree before they know the write rate. The rate is what tells you whether the index has to live in memory and how to split it.
The sentence candidates skip: "If a million drivers send an update every four seconds, that's 250,000 writes a second. Those can't all go to one database."
8. Design search autocomplete
It mostly grades requirements, specifically the latency one. Suggestions have to come back before the next keystroke, and that single requirement decides most of the design: a prefix index, top results computed ahead of time for each prefix, and caching close to the user.
The sentence candidates skip: "What's the latency budget per keystroke? That tells me whether I can rank at query time or have to precompute."
9. Design a payment system
It mostly grades trade-offs. Payments are where consistency beats availability, and the interviewer wants you to say so and design for it: idempotency keys on every request, a double-entry ledger, and reconciliation against the payment provider's records.
Idempotency tends to come up only when I ask what happens on a retry, and by then it sounds like a patch.
The sentence candidates skip: "If we can't confirm the charge, we show it as pending. That's better than risking charging twice."
10. Design a metrics and monitoring pipeline
It mostly grades the data model. Metrics arrive as a very high rate of small writes and are read as aggregates over time windows. A time-series layout, downsampling of old data and retention tiers follow from that.
The sentence candidates skip: "What's the label cardinality? Every extra label multiplies the number of series we store."
11. Design video streaming
It mostly grades requirements. Live and on-demand video are almost different systems. On demand, the design is an upload pipeline, transcoding into several bitrates, adaptive streaming and a CDN that serves nearly all of the bytes. Live adds latency targets that change most of those choices.
The sentence candidates skip: "Is this live or on demand? The answer changes the whole pipeline."
12. Design a distributed cache
It mostly grades trade-offs. Consistent hashing, eviction policy, replication, cache-aside vs write-through, and how stale a read is allowed to be: every one of these is a choice with a cost, and the interviewer expects you to name it.
Most candidates name LRU and move on. Eviction is the easy part. The stampede question is where I find out whether someone has run a cache under load.
The sentence candidates skip: "What happens to the database when a popular key expires and a thousand requests miss at the same moment?"
The signal most candidates miss
If I had to name one, it's the scaling story. Candidates draw the right components and never put a number next to them, so the interviewer can't tell whether they know where the design breaks. One line of arithmetic after the requirements fixes most of it: requests per second, data per year, and the read-to-write ratio.
A 45-minute time budget
Most system design rounds run 45 to 60 minutes. Here is how I'd split 45. In a 60-minute round, give the extra time to the deep dive.
| Minutes | Phase | Signal on show |
|---|---|---|
| 0–5 | Requirements and scope | Requirements |
| 5–10 | Estimates: traffic, storage, read-to-write ratio | Scaling story |
| 10–15 | API and data model | Data model |
| 15–30 | High-level design, then one component in depth | Scaling story, trade-offs |
| 30–40 | Bottlenecks, failures, what changes at ten times the load | Trade-offs |
| 40–45 | Summary and your questions | Communication |
The table is a default. If the interviewer steers you toward a component at minute 12, follow them, because where they steer is usually where the grading is.
How to practise with a timer
- Pick a prompt you haven't done before and set a 45-minute timer.
- Talk out loud the whole time and record it. Silence reads as being stuck, even when you're thinking.
- Draw on a blank whiteboard or a plain drawing tool, without a template.
- Stop when the timer ends, even mid-design. The clock is part of the test.
- Score the recording afterwards on the five signals, from 1 to 10 each. Your memory of the session will be kinder than the tape.
- A week later, redo the same prompt and focus only on the lowest row.
Solo practice has a ceiling. It can't reproduce an interviewer who interrupts, pushes back on a choice or moves you to a different component halfway through, and handling those moments is part of the communication grade. The system design interview prep post covers how to run a mock with someone in that seat.
System design interview cheat sheet
Here is the whole post on one screen. The right column is the question to ask yourself in the first ten minutes.
| Prompt | Mostly grades | Ask yourself |
|---|---|---|
| URL shortener | Data model | How are keys generated without collisions? |
| Rate limiter | Trade-offs | Fail open or fail closed? |
| News feed | Scaling story | What happens when a huge account posts? |
| Chat | Requirements | Which ordering guarantee do we need? |
| Notifications | Communication | Which channel do I design in depth? |
| File storage and sync | Data model | How are files chunked and addressed? |
| Ride matching | Scaling story | How many location writes per second? |
| Search autocomplete | Requirements | What's the latency budget per keystroke? |
| Payments | Trade-offs | How do we never charge twice? |
| Metrics pipeline | Data model | What's the cardinality? |
| Video streaming | Requirements | Live or on demand? |
| Distributed cache | Trade-offs | What happens when a hot key expires? |
Estimates worth knowing by heart:
- A day has 86,400 seconds, close enough to 100,000 for interview arithmetic.
- A million requests a day is about 12 a second. A billion a day is about 11,600 a second.
- Peak traffic is some multiple of the average, so say which multiple you're assuming.
System design in cloud and architect rounds
Solutions architect and cloud engineer loops often add short AWS scenarios to the whiteboard round, such as "S3, EBS or EFS?" or "how would you survive a Region outage?". They're graded on the same five signals. The AWS interview questions post covers the common ones by area, and the AWS solutions architect interview questions post goes deeper on the architect round.
If the role also asks for an AWS certification, the exam guide covers much of the same service knowledge. The AWS certification path lists every exam and the one that fits each role, and Track A of my coaching starts with a gap assessment against the guide.
FAQ
What are the most common system design interview questions?
The ones in most published question banks: a URL shortener, a rate limiter, a news feed, a chat app, a notification system, file storage and sync, ride matching, search autocomplete, payments, a metrics pipeline, video streaming and a distributed cache. It's worth learning which signal each one mostly grades.
How should I prepare for a system design interview?
Learn the building blocks first: load balancers, caches, queues, databases, partitioning and replication. Then practise timed mocks out loud, one prompt in 45 minutes, and score each one on requirements, data model, scaling story, trade-offs and communication. Between mocks, work on the weakest of the five.
What are the four pillars of system design?
There's no official list. Articles that use the phrase usually mean scalability, availability, reliability and performance. They're useful words to have, but an interviewer scores how you reason about them for one prompt, which shows up as requirements, data model, scaling story, trade-offs and communication.
How long is a system design interview?
Usually 45 to 60 minutes, with a few minutes at the end for your questions. Expect about 35 minutes of actual design, and practise with a timer so the clock doesn't surprise you.
Do I need to know AWS for a system design interview?
Not for most software engineering loops, which are vendor-neutral. Naming a managed service is fine if you can say what it does and what you give up by using it. Solutions architect loops are different and can expect service-level depth on the platform the role is for.
Practising with someone in the interviewer's seat
A question bank won't show you which of the five signals is missing from your answers, and that's hard to see from the inside. A mock system design interview will.
In a system design mock I run one of these prompts against the clock, score it on the same five rows, and send you the written scorecard within a day. Sessions run on weekday evenings and at weekends, in English or Ukrainian.