System design interview questions: how to prepare

System design interview questions are open-ended design discussions, so your best preparation is a spoken, requirements-first process rather than a memorised collection of diagrams. This guide covers what the round tests, a framework for structuring an answer, the concepts behind common prompts, and the extra concerns in AI and machine learning design.

Rather than looking for one perfect architecture, show how you make a decision when information is incomplete. A good answer makes its assumptions visible, connects each component to a requirement, and explains what would change if the traffic, data, reliability, or cost constraint changed. System design interview preparation works best when you practise that kind of reasoning aloud.

What a system design interview is

A system design interview is a technical hiring exercise in which you discuss how you would build or evolve a system. The interviewer gives you a problem with deliberate gaps, then follows the thread of your reasoning: what you ask first, what you choose, what you defer, and how you deal with failure. It is different from a fact-recall quiz because several designs can be reasonable when their trade-offs fit the stated goal.

The conversation can cover high-level design, such as the major services and data flow, or low-level design, such as the boundaries and behaviour of a component. Amazon's published software-development interview topics include system-design whiteboarding among technical interview preparation. Treat the prompt as a shared design session, not a request to recite a diagram you have seen before.

What interviewers look for

First, they look for problem framing. Before choosing a database or drawing a queue, establish who uses the system, what success means, which operations matter most, and which constraints are real. That early conversation prevents a fast but irrelevant answer and gives you a basis for every later choice.

They also look for practicality. A useful design has a clear request path, a place for data to live, a plan for growth, and an explanation of what happens when a dependency is slow or unavailable. Amazon's preparation guidance describes objectives including practicality, accuracy, efficiency, reliability, optimisation, and scalability in its SDE III interview preparation.

Finally, they look for communication and trade-off thinking. Say why a simple version is enough for the current requirement, then identify the signal that would make you add complexity. You do not need to claim that a component is universally best; you need to show what it improves and what it costs in latency, operations, consistency, or implementation effort.

A framework for answering any system design question

Use the same sequence for familiar and unfamiliar system design interview questions. It keeps the conversation understandable and lets the interviewer redirect you before you build too much.

1. Clarify the problem and success criteria. Ask about users, important actions, read and write paths, data sensitivity, availability needs, and what is explicitly out of scope. Repeat the agreed problem in one sentence before designing.
2. State assumptions and make rough estimates. Identify the main workload and whether demand is steady, bursty, read-heavy, or write-heavy. Use estimates to justify a direction, not to manufacture precision that the prompt did not provide.
3. Define the API and data model. Name the key objects, the operations clients need, and the data each operation reads or changes. This is where a vague box diagram becomes a design that can be tested for correctness.
4. Draw the high-level request and data flow. Start with the smallest end-to-end version: client, entry point, application work, persistent data, and response. Label the ownership of state so the interviewer can follow a request without guessing.
5. Deep dive where the requirement creates risk. Explore the component that dominates the prompt, such as a cache for repeated reads, a partition strategy for uneven writes, or a queue for delayed work. Do not spend equal time on every box.
6. Close with failure modes and trade-offs. Describe what happens when a dependency fails, data is delayed, demand changes, or a request is repeated. Summarise the decision you made and the alternative you would choose under a different constraint.

This sequence is a map, not a script. Pause after each stage for questions, and revise the design when the interviewer adds a requirement. That responsiveness is stronger evidence of engineering judgement than reaching a predetermined final diagram.

The core concepts you need

Scaling

Scaling means keeping a useful service available as demand grows or becomes uneven. Start by separating work that can run on any application instance from work that needs shared state. A stateless tier can be expanded horizontally, while sessions, uploads, and durable records need a shared store or an explicit ownership rule.

Say what metric would trigger the next change: slow responses, a saturated dependency, a growing backlog, or a capacity limit. Then explain the dependency that becomes the next bottleneck after you add instances. Work through a practice question on scaling out a stateless tier to test the distinction between adding application capacity and leaving per-user state on one server.

Caching

A cache keeps a reusable result closer to the work that needs it, reducing repeated reads from a slower source. In an interview, identify the key, what invalidates it, who can tolerate an older value, and what happens when it is empty. Those details matter more than merely adding a cache box to a diagram.

Plan for concentrated demand as well as normal hits. If many requests miss the same recently expired value, they can overload the original data source together. Use a practice question on cache stampede for a hot key to practise explaining request coalescing and the reason it protects the backing service.

Load balancing

A load balancer distributes traffic so one application instance does not receive all the work. In your answer, describe the boundary where traffic enters, how unhealthy instances stop receiving requests, and whether the routing decision needs to understand the request itself. The right choice depends on the requirement, not on the label of the load balancer.

For example, routing based on an HTTPS hostname or URL path needs the routing layer to inspect application-level information; simple transport forwarding does not. Take a practice question on Layer 4 versus Layer 7 path routing to explain that boundary without turning it into a vocabulary exercise.

Databases and sharding

Choose a data store from the access pattern and correctness requirement. Explain what must be queried together, which updates must be atomic, and which data can be derived later. Naming a database without connecting it to reads, writes, and failure behaviour leaves the important design work unfinished.

Sharding partitions data so its storage and work can be spread across owners. A good shard key spreads the expected workload, while a weak one can put one busy tenant or category on a single partition. Use a practice question on a hot tenant shard key to practise choosing a higher-cardinality key and naming the trade-off it introduces.

Queues

A queue separates accepting work from completing it. Use one when an operation can happen later, when producers and consumers need to scale independently, or when a temporary downstream failure should not immediately fail the user-facing request. Describe the consumer, retry path, observability, and what prevents a repeated delivery from causing a repeated business effect.

That last point is idempotency: processing the same message more than once should lead to the same safe outcome. Use a practice question on an idempotent payment consumer to see how an idempotency key can make retries safe for a sensitive workflow. For a broader look at event-routing choices, see SQS, SNS and EventBridge.

Consistency and CAP

Consistency questions begin with a business invariant, not an acronym. Ask whether a stale read, a duplicated action, or a temporarily rejected request would do more harm for this operation. During a network partition, the CAP trade-off makes that decision visible: you cannot promise both an always-available response and a single current view of data across the separated sides.

Start with a practice question on choosing consistency during an inventory partition to state the harm of duplicate sales. Follow it with a practice question on read-your-writes consistency for a profile to distinguish a user-visible guarantee from global synchronisation. Then use a practice question on acknowledged-write loss after asynchronous replication failover to connect the choice to a real failure outcome; the AWS disaster recovery strategies guide adds related recovery vocabulary.

Common system design interview questions

Do not study common prompts as isolated products. Group them by the decision pattern they expose, then practise moving that pattern to a new domain. The following are original prompt shapes, not questions copied from an interview or a preparation site.

A bursty shared resource

You might be asked to design a service where many people request the same limited resource at the same time. This tests requirement clarification, admission control, cache behaviour, and the correctness boundary around the final allocation. Begin by separating browsing from committing, then explain how the design prevents the last available item from being promised twice.

A read-heavy personalised service

A prompt may describe frequently viewed profiles, feeds, or settings that must feel responsive while remaining appropriate to each user. This pattern tests cache keys, invalidation, read consistency, and separation of public from private data. A strong answer says which values may be slightly old and which must reflect the user's latest action.

Delayed work with an important side effect

Another pattern accepts a request now but performs a notification, record update, or payment step later. It tests queues, retries, duplicate handling, and the distinction between accepting a request and confirming completion. Make the failure path explicit: where work waits, what a worker does after a timeout, and how the user can learn the eventual result.

Uneven data growth

Some systems grow because a few customers, locations, or categories become much busier than the rest. This pattern tests data modelling and partitioning rather than simply adding application servers. Explain how you detect the hot partition, what key you would reconsider, and how the change affects queries that need data from more than one shard.

A dependency that can fail or fall behind

Prompts about regional failure, delayed replicas, or an unavailable downstream service test your reliability reasoning. Describe the user experience you preserve, the operation you temporarily refuse or delay, and how the system reconciles later. The point is not to declare that no data can ever be lost; it is to make the recovery promise match the value of the operation.

AI and machine learning system design interviews

AI and machine learning system design starts with the same system questions, then adds a model and its lifecycle. You still clarify the user action, latency, reliability, privacy, and cost constraint. On top of that, explain where data comes from, how it is checked, how features or retrieved context reach the serving path, and how you know whether the result remains useful.

Separate training from serving. Training prepares or updates a model from historical data, while serving makes a prediction or produces a response for a live request. Microsoft's technical interviewing guidance lists experience with ML models and training pipelines, including evaluation, profiling and optimisation, among its role requirements, and production ML research from Google describes the importance of data validation and serving infrastructure in its TFX paper.

For an AI prompt, make evaluation concrete before discussing a model choice. Define what a good answer or prediction means, how you measure quality before release, how you observe live results, and what fallback exists when confidence, relevance, latency, or cost is poor. A design that includes rollback and monitoring is more credible than one that assumes model output is always correct.

RAG prompts need the same discipline. Explain the document intake path, retrieval boundary, context supplied to the model, and how you evaluate whether the answer used relevant material. The introduction to retrieval-augmented generation and RAG versus fine-tuning can help you separate those approaches before you practise describing one under interview constraints.

System design for freshers vs experienced candidates

Do not assume that every role gives the same design round or that job titles imply a universal depth. Published company guidance varies by role and stage, and none of it draws a clean line between freshers and experienced candidates. Read the employer's materials for the specific opening and use the interview invitation to understand the scope.

If you are earlier in your career, build confidence by explaining a small, coherent design well: requirements, data ownership, a request path, and one thoughtful trade-off. It is better to state an assumption and invite correction than to imitate production experience you do not have. For an experienced role, be ready to take the same foundation further into migration, operational risk, failure recovery, and the consequences of changing a live system.

In either case, your preparation should be honest about the work you have done and precise about the reasoning you can demonstrate. A familiar prompt is useful only if you can adapt it when a follow-up changes the reliability, cost, or data requirement.

How to practise system design

Start with free primary material: Amazon's SDE III preparation, Microsoft's technical-interview guide, and Google's SRE book give you company or engineering perspectives without requiring a course. Use them to understand how interviewers frame the conversation before you start practising prompts.

Practise aloud with a blank page. Pick one pattern, spend the opening moments clarifying the problem, draw the smallest end-to-end path, and then ask yourself the follow-up that would most challenge the design. Record the explanation or practise with another person, then review whether you named an assumption, justified each major component, and described a failure mode.

Use the System Design practice bank for timed decision practice, and use its question list to revisit a weak concept by topic. After each attempt, write one change you would make if reads increased, data became more sensitive, or a dependency became unavailable; that is how a static answer becomes reusable interview judgement.

Frequently asked questions

What is system design?

System design is the process of deciding how parts of a software system work together to meet a need. It includes the request flow, data, components, growth path, and behaviour when something fails. In an interview, the important part is explaining why the design fits the stated requirements.

What is the difference between HLD and LLD?

High-level design focuses on the major components, data flow, boundaries, and trade-offs across a system. Low-level design goes deeper into how a component behaves, such as its interfaces, data structures, and internal responsibilities. A prompt can begin at the high level and then ask you to deepen one risky or important component.

What should I expect in a Google system design interview?

Do not assume a fixed format from the phrase “Google system design interview.” Formats vary by role and interview stage, so ask your recruiter what the design round covers for your level. Prepare a clear, requirements-first design conversation rather than relying on a generic level rule from a prep site.

What is an AI system design interview?

It is a system design discussion that includes an AI or machine learning capability and its lifecycle. Along with services and data, you need to address data quality, training or retrieval, serving, evaluation, monitoring, latency, cost, and a fallback when output is unsuitable. The best answer connects the model to a user outcome instead of treating it as an isolated black box.

How long should I prepare for a system design interview?

There is no universal preparation length because the expected format and depth vary by employer, role, and stage. Prepare until you can take an unfamiliar prompt through requirements, a coherent first design, one focused deep dive, and explicit trade-offs aloud. Repeated short reviews of your own explanations reveal gaps better than collecting more diagrams.