System design interview questions: a framework and the common prompts

System design interview questions ask you to design a large software system, such as a URL shortener, a news feed or a chat service, in about 45 minutes, by talking through requirements, a high-level architecture and the trade-offs. There is no single right answer. Interviewers score how you structure the problem, choose between options and defend those choices.

What is a system design interview?

A system design round gives you a vague product prompt and a whiteboard or shared canvas. "Design a service that shortens links." "Design a chat application." You are expected to ask questions, size the problem, sketch the components, and go deep on a few of them. The interviewer plays the role of a colleague who can answer questions and push on your choices.

It differs from a coding round in one important way. The goal is not a correct output. It is a reasoned argument. Two candidates can draw the same boxes and score very differently, because one explained why a cache goes there and what happens when it fails, and the other did not.

A framework that works for most questions

A fixed order keeps you from drawing boxes before you know what they are for. Most strong answers follow some version of this sequence.

1. Clarify requirements. Ask what the system must do and what it must not. Separate functional requirements (create a short link, redirect) from non-functional ones (low latency, high availability, durability). Confirm scope out loud so the interviewer can correct you early.
2. Estimate the scale. Rough numbers for users, requests per second, and storage. Precision does not matter. The numbers decide whether you need sharding or whether one database is fine.
3. Sketch the high-level design. Clients, entry point, services, data stores. Draw the main path first, usually the write and the read.
4. Define the data and the API. A few endpoints and the shape of the key records. This is where access patterns become clear, and access patterns drive the choice of store.
5. Go deep on two or three components. Pick the parts where the real difficulty lives and where the interviewer shows interest. Key generation for a shortener, fan-out for a feed, ordering for chat.
6. Name the trade-offs and failure modes. What breaks first, what you gave up, and what you would change at ten times the load.

The clock matters as much as the order. A design that spends 35 of 45 minutes on the high-level sketch never reaches the deep dive, which is the part that is scored. System design mock interview under a clock breaks the time into phases you can rehearse.

Requirements and estimation

Start with questions, and keep them short. Who uses this? Read-heavy or write-heavy? How fresh must the data be? What happens if it is briefly unavailable? Each answer eliminates a branch of the design, and each one shows the interviewer you work from constraints.

Then size the problem with round numbers. Suppose a service creates 100 million records a day. That is about 1,200 writes per second (100 million divided by roughly 86,400 seconds). If reads outnumber writes by 100 to 1, you are near 120,000 reads per second, and the read path becomes the design. Those figures are assumptions you state, not facts you look up, and you should say so. If the interviewer gives different numbers, use theirs.

A worked example of this step is in design a URL shortener, diagrammed.

The building blocks you should know cold

Most designs combine the same dozen parts. You do not need product names. You need to know what each is for and what it costs.

• Load balancer: spreads requests over servers and removes unhealthy ones. Cost: another component that must not be a single point of failure.
• Cache: holds hot reads in memory to cut latency and database load. Cost: staleness, invalidation, and a cold start.
• Relational database: strong consistency, joins and transactions. Cost: harder to scale writes horizontally.
• Key-value or wide-column store: fast lookups by key at large scale. Cost: limited querying, and you design around the access pattern.
• Message queue: decouples producers from consumers and absorbs bursts. Cost: delayed processing, duplicates, and ordering questions.
• Object storage and CDN: cheap storage for large files and edge delivery. Cost: eventual freshness and cache control.
• Search index: full-text and ranked lookups. Cost: a second copy of the data that must be kept in sync.
• Rate limiter: protects services from abuse and overload. Cost: shared state and false rejections.

When you place one in a diagram, say why it is there and what you are trading. "I would put a cache here because reads dominate, and I accept stale data for a short window" is a complete sentence. A box with no sentence is not.

The trade-offs interviewers keep returning to

Consistency versus availability

When a network partition or a node failure occurs, a distributed system must choose between returning possibly stale data and refusing requests. Decide which the product can tolerate. A bank balance and a like count do not need the same answer.

SQL versus NoSQL

Do not pick by fashion. Ask about the access pattern. If you need transactions across several records and flexible queries, a relational database is a reasonable default. If you need single-key lookups at very high volume with simple records, a key-value store fits. Say what you are giving up.

Push versus pull

In a feed, you can compute each user's timeline when a post is written (push) or when it is read (pull). Push makes reads fast and writes expensive. Pull is cheaper to write and slower to read. Accounts with very many followers often force a hybrid.

Synchronous versus asynchronous work

Anything not needed to answer the user belongs off the request path. Analytics, notifications and thumbnail generation are common examples. Moving them to a queue protects the latency of the main path.

Sharding and hot keys

Splitting data across machines raises questions about the shard key and about uneven load. A single very popular key can overload one node even if the data is evenly spread. Know the usual answers: replicate the hot item, cache it at the edge, or add a random suffix to spread it.

Common system design interview questions

These come up often. Each tends to hinge on one hard part, and knowing that part is more useful than memorizing a full design.

• Design a URL shortener. The hard part: generating unique short keys without collisions, and optimizing the read path.
• Design a rate limiter. The hard part: sharing counters across servers, and choosing an algorithm such as token bucket or sliding window.
• Design a news feed. The hard part: fan-out on write versus on read.
• Design a chat system. The hard part: delivery, ordering and presence at scale.
• Design a file storage service. The hard part: chunking, deduplication and sync conflicts.
• Design a notification system. The hard part: reliable delivery, retries and user preferences.
• Design a web crawler. The hard part: politeness, deduplication and a large frontier.
• Design a ride-hailing backend. The hard part: matching nearby supply to demand with fast location updates.

Start with the URL shortener if you have not practiced one. It is small enough to finish in a sitting and rich enough to cover keys, caching, sharding and an analytics side path.

How to communicate during the round

Interviewers consistently say communication separates candidates with similar technical depth. A few habits help.

• Narrate decisions, not just components. "I am choosing X over Y because Z."
• State assumptions and check them. "I will assume reads dominate. Is that right?"
• Pause at phase boundaries and ask whether to go deeper or move on.
• Name your own weak spot before they do. "This design has a single database, which is a risk. I would add a replica."
• When pushed, defend or change your view with a reason. Folding instantly and digging in without thought are both weak.

A short walkthrough: a rate limiter

A compact example shows the framework working. The prompt is "design a rate limiter for an API".

1. Clarify. Is it per user, per API key or per IP? Is a rejected request dropped or queued? Must the limit hold across many servers? Suppose the answers are per API key, drop with an error, and yes across servers.
2. Estimate. Say 50,000 requests per second across all keys. A counter lookup on every request is a hot path, so it must be in memory and fast.
3. High level. Requests reach a gateway, which asks a counter store whether the key is under its limit, then forwards or rejects.
4. Data and API. The record is a key, a count and a window. The decision is a yes or no returned in a millisecond or two.
5. Deep dive. Compare a fixed window, which is simple but allows a burst at the boundary, with a token bucket, which allows controlled bursts and needs a refill timestamp. Then discuss atomic updates in a shared store so two servers do not both see room.
6. Trade-offs. If the counter store is down, do you fail open and risk overload, or fail closed and risk rejecting everyone? Pick one and give the reason.

Notice that nothing here required a rare technology. The substance is the choice between algorithms and the failure behavior.

Failure modes worth naming

Many candidates describe the happy path and stop. Interviewers notice when you volunteer the unhappy one. A quick checklist you can run on any design:

• What happens when this component is down? Is there a replica, and who promotes it?
• What happens when it is slow rather than down? Timeouts, retries and backoff.
• What happens under a burst? Queues, load shedding, backpressure.
• What happens to data in flight? Duplicates, lost messages, idempotency.
• What happens when one tenant or key is far larger than the rest? Hot spots.

You do not need a full answer to each. A one-sentence acknowledgement with a direction, such as "I would make this write idempotent so retries are safe", shows you think about operating the system and not only drawing it.

How expectations change with seniority

The same prompt is graded differently by level. For a junior or mid-level role, a clear and correct basic design with sensible components is often enough. For senior roles, interviewers expect you to drive the conversation, surface the hard problem unprompted, and reason about operations, cost and evolution. For staff-level roles, expect questions on organizational constraints, migration paths and what you would build first. If you are unsure of the level, ask the recruiter what the round emphasizes.

Common mistakes

1. Drawing before asking. A design with no requirements cannot be wrong or right, and the interviewer cannot tell what you value.
2. Listing every technology. Naming ten products is not depth. One component explained well is worth more.
3. Skipping the numbers. Without estimates you cannot justify a cache, a shard or a queue.
4. Never choosing. Presenting every option as equal looks like indecision. Pick one and say what it costs.
5. Running out of time. Rehearse the phases so the deep dive actually happens.

How to practice system design

Reading designs is the easy half. The hard half is producing one aloud under a clock. A practice loop that works:

1. Pick one question a week. Do it end to end rather than skimming several.
2. Set a 45-minute timer and speak. Talk through every phase, even alone. Record it if you can.
3. Review against the framework. Did you clarify, estimate, go deep, name trade-offs? Mark the phase you skipped.
4. Redo the weak phase. Repeat just that phase the next day.
5. Learn the building blocks separately. Cache invalidation and sharding deserve their own short sessions.

URHIRED AI's System design surface returns an overview, a component list and a rendered diagram, so you can see a structure and then redraw it in your own words. Use Hints mode when you practice: it nudges you toward the next step without handing over the design, which keeps the reasoning yours. Free practice is 15 session minutes a day, and scored mocks need a paid plan. See the interview copilot overview and the pricing page.

If you plan to use any tool during a real round, check the employer's rule first. Is using an AI interview copilot cheating explains how to sort prep from live. You speak or type every answer yourself.

Where to go next

• Practice one full design: design a URL shortener, diagrammed.
• Rehearse the clock: system design mock under a clock.
• Not sure how a copilot fits? Read what is an AI interview copilot, or download the app and try a session.