# System design interview preparation: a practical guide Clarify the requirements, state your assumptions, and draw a simple end-to-end design. Use estimates to justify decisions, then examine failure behaviour, scaling limits, and operational trade-offs. Practise explaining why each component is needed instead of memorising a diagram. About 7 min read. ## On this page - [What should you practise for a system-design interview?](https://preprole.com/guides/system-design-interview-preparation#purpose) - [Clarify the problem before drawing the architecture](https://preprole.com/guides/system-design-interview-preparation#requirements) - [Use estimates to answer a design question](https://preprole.com/guides/system-design-interview-preparation#estimates) - [Start with a baseline you can trace end to end](https://preprole.com/guides/system-design-interview-preparation#baseline) - [Discuss retries, duplicates, and backpressure honestly](https://preprole.com/guides/system-design-interview-preparation#failure) - [Make the design observable and safe to operate](https://preprole.com/guides/system-design-interview-preparation#operations) - [Rehearse decisions, not a memorised diagram](https://preprole.com/guides/system-design-interview-preparation#practice) ## What should you practise for a system-design interview? Practise turning an ambiguous problem into a design whose decisions you can explain. Start with requirements, choose a simple baseline, trace the data flow, and examine the most important failure or scaling concern. Naming many infrastructure products is not a substitute for reasoning. A design is useful only in relation to the requirements it is meant to satisfy. Ask the recruiter about scope and seniority expectations. Some interviews emphasise a broad service architecture; others focus on object modelling, a subsystem, or an existing design. Amazon's preparation page lists distributed computing, databases, and object-oriented design among its technical topics and discusses whiteboarding. That describes its preparation guidance, not a universal sequence for every employer. Reference: [Amazon Careers: software development interview topics](https://amazon.jobs/content/en/how-we-hire/interview-prep/software-development-topics) ## Clarify the problem before drawing the architecture Restate the user's goal and separate the behaviours the system must support from its operating constraints. For a notification service, sending an account alert is a behaviour; a delivery-time target or retention requirement is a constraint. Ask which channels, users, and failure cases matter. A design for occasional email reminders differs from one for urgent multi-channel alerts. Write down assumptions when the interviewer leaves a detail open. State what you are excluding for the first version, such as scheduled campaigns or channel preferences. Scope is an agreement you may revisit, not a way to avoid hard requirements. Confirm the most important user flow so that the rest of the conversation has a shared reference point. - Who requests the action, and who receives the result? - What must happen synchronously, and what can happen later? - Which failures are acceptable, visible, or recoverable? - What are the traffic, data-retention, and privacy constraints? ## Use estimates to answer a design question Estimate only what will help you choose a design. For an illustrative notification service, assume 100,000 active users and ten notifications per user each day. That is one million notifications a day, or about 11.6 per second on average. These are invented exercise inputs, not PrepRole usage figures or a prediction of real traffic. An average is not a peak. If you additionally assume a ten-times burst, the service would need to handle about 116 requests per second during that burst. Neither assumption tells you the downstream provider's rate limit, the amount of retry traffic, or how long a burst lasts. Ask or state those uncertainties before selecting infrastructure. If each stored event were one kilobyte, the raw event payload would be roughly one gigabyte per day using decimal units. Indexes, metadata, replication, and backups add storage beyond that. The point is to connect retention and access patterns to the storage decision and identify which missing facts could change it, not to display arithmetic. ## Start with a baseline you can trace end to end One possible baseline accepts a request through an authenticated API, records a notification and its state in a database, and lets a worker deliver it through a provider. The caller receives confirmation that the request was accepted, not a false claim that the recipient has received it. A status endpoint can expose queued, attempted, delivered, or failed states only where the provider gives enough evidence. Trace one successful request through the design. Identify where an identifier is created, which state is durable, and when the client can safely retry. Then trace a failed request. A durable work record can be sufficient for an initial worker design; an external queue is a choice to justify, not a compulsory box in every architecture diagram. If a database write and queue publish are separate operations, explain the failure between them. An outbox pattern is one possible approach: save the business record and pending event in the same database transaction, then publish later. It introduces its own worker and deduplication concerns. Discuss whether that complexity is justified by the reliability requirement. ## Discuss retries, duplicates, and backpressure honestly A worker may send a request and lose the response even though the provider accepted it. Retrying can therefore duplicate a side effect. An idempotency key or deduplication record can help within defined boundaries, but it does not magically create exactly-once delivery across every external system. State what the provider supports and what remains uncertain. Use bounded retries with a suitable delay policy for transient failures, and distinguish them from permanent failures such as an invalid destination. Explain what happens when attempts are exhausted and who can inspect or replay failed work. A retry mechanism needs limits; otherwise it can turn an upstream outage into sustained overload. For a backlog, consider queue age as well as queue length, the provider's throughput limit, and the acceptable delivery delay. Adding workers is not useful if the downstream service is already rate limited. Describe how you would slow acceptance, prioritise work, or communicate delayed delivery under the requirements you agreed earlier. ## Make the design observable and safe to operate Name the signals that would tell an operator the service is failing: processing latency, oldest pending work, provider errors, retry counts, and permanent failures. Connect each signal to an action or investigation. A dashboard full of counters is less useful than an explanation of how you would distinguish a slow provider from a broken worker. Include authorisation, retention, and sensitive-data handling in the design rather than treating them as a final checklist. Restrict who can send a notification or view its status. Avoid storing or logging message content when an identifier and outcome are sufficient. Choose retention based on the use case and applicable requirements, not the convenience of keeping everything indefinitely. ## Rehearse decisions, not a memorised diagram Run one practice session from requirements to a minimal design. In the next session, keep the same prompt but change a constraint: stricter delivery delay, a provider outage, or a smaller operations team. Notice which decisions change and which remain justified. This is more revealing than redrawing the same architecture more neatly. At the end, summarise the design, its most important trade-off, and the main unresolved risk. Ask a listener to name those three things. If they remember only the technology names, make the reasoning more explicit. Review one unclear explanation before adding a new system-design topic to your preparation list. ## Frequently asked questions ### Should I always start with a distributed architecture? No. Begin with the requirements and a baseline you can explain. Add distribution when the availability, scale, latency, or organisational constraints justify it. Additional components create operational and consistency costs that you should be able to discuss. ### Do I need exact traffic numbers? Usually you need defensible assumptions rather than invented precision. State the units, distinguish average from peak, and explain how an estimate affects the design. Ask which workload or service constraint is important before spending time on arithmetic. ### What should I draw on the whiteboard? Draw the components and flows needed to explain the agreed use case. Mark the durable state, the request or event path, and an important failure boundary. Keep labels readable and add detail when it answers a question rather than filling every part of the board. ### Is there one correct system-design answer? Different designs can satisfy different constraints. Explain the assumptions, costs, and failure behaviour behind yours. Revisit a choice when the interviewer changes a requirement. A familiar architecture is not automatically suitable for the prompt in front of you. ## Practise the next answer Choose System Design and use the Whiteboard to trace the important flows. Invite follow-up questions about one decision rather than filling the board with components. Review your Scorecard for explanations you can make clearer; an AI-generated Verdict is not a hiring decision. Practise for your job: https://preprole.com/setup ## Sources and scope Employer sources describe their own processes, which may change. The exercises and illustrative examples are PrepRole editorial guidance, not employer questions or hiring criteria. - [Amazon Careers: software development interview topics](https://amazon.jobs/content/en/how-we-hire/interview-prep/software-development-topics) - [Microsoft Careers: interview tips for all roles](https://careers.microsoft.com/v2/global/en/hiring-tips/interview-tips.html) ## Related guides - [Explain technical decisions from a real project](https://preprole.com/guides/technical-deep-dive-interview) - [Understand the Whiteboard and Interview Stages](https://preprole.com/guides/stages) - [Use a Scorecard to choose your next practice task](https://preprole.com/guides/scorecards) AI feedback can be wrong. A practice Verdict is not a hiring decision.