A repeatable method for system design interviews and design reviews

The problem: an empty whiteboard

You are given a sentence such as "design a notification service" and forty-five minutes. Many candidates do one of two things: they start drawing boxes labelled Kafka and Redis immediately, or they freeze because the problem is open-ended. Both fail for the same reason: there is no process. The interviewer is not looking for the single correct architecture. They want to see how you reduce ambiguity, reason about numbers, make choices and notice what can go wrong.

The same skills matter outside interviews. A design review at work is a system design interview where the answers have consequences. A method that is easy to repeat keeps you calm and keeps the conversation useful.

The method in eight steps

1. Clarify requirements and scope

Ask questions before drawing. Separate functional requirements (what the system does) from non-functional ones (latency, availability, consistency, durability, security). Agree on what is out of scope. For a notification service, useful questions are: which channels (email, push, SMS), is delivery time-sensitive, must a notification never be lost, can it be sent twice, how many recipients per event?

2. Estimate roughly

You need orders of magnitude, not precision. Write assumptions down and label them. For example: assume 5 million users, 2 notifications per user per day, so 10 million per day, about 115 per second on average. Assume peaks of 10x, so about 1,200 per second. The point is to learn whether you are designing for tens, thousands or millions per second, and whether storage or throughput will dominate.

3. Define the API and core entities

Sketch two or three endpoints or events and the main data entities. This forces precision about inputs and outputs and exposes missing requirements early.

POST /v1/notifications
{ "userId": "u-42", "template": "order-shipped",
  "channel": "push", "idempotencyKey": "evt-9981" }
-> 202 { "id": "n-1001", "status": "QUEUED" }

Entities: Notification(id, userId, channel, status, createdAt)
          Preference(userId, channel, enabled)

4. Draw a high-level design

Start with the simplest thing that satisfies the requirements and add components only when a requirement demands them.

Client -> API -> Queue -> Sender workers -> Provider (email/push)
            |                    |
            v                    v
        Preferences DB      Notification DB (status)

Explain the request path end to end, then say which components are stateless and which hold state.

5. Deep dive where the risk is

Pick the one or two parts that are hardest or most relevant: ordering, duplicates, hot partitions, rate limits of external providers, retries. Interviewers often steer you here. Show depth in one area instead of shallow coverage everywhere. For notifications, a good deep dive is at-least-once delivery with idempotent sending, which links to idempotency patterns.

6. Discuss trade-offs explicitly

For each important choice, state the alternative and why you did not take it: a queue adds latency and operational cost but absorbs bursts; synchronous calls are simpler but couple availability to the provider. A phrase like "I chose X because requirement Y outweighs the cost Z" is stronger than any technology name.

7. Cover failure modes

Ask "what breaks?" for each component: a provider is down, the queue is full, a worker crashes mid-send, a database fails over. Mention timeouts, retries with backoff, dead-letter handling, backpressure and degraded behavior. See distributed systems failure for the vocabulary.

8. Summarize and name what you would do next

Close by restating the design in a few sentences, listing known weaknesses, and saying what you would measure or build next: observability, load tests, security review, cost.

What interviewers usually listen for

Across companies, the signals tend to be similar: Do you ask before you build? Can you reason with rough numbers? Do you choose the simplest design that meets the requirement? Can you explain a trade-off without defending a favourite tool? Do you notice failure? None of these require memorized architectures. They require a habit of structured thinking, which is exactly why a repeatable method helps under pressure.

Time budget for a 45-minute session

Treat these as a guide; adapt to what the interviewer asks.

A small example: the steps working together

For a "short link service", in the first two minutes you ask about requirements: redirects must be fast, links must not be guessable, click counts are needed. Rough numbers then show the system is read-heavy, which justifies a cache and defers sharding. You sketch the API, draw the simple design, then choose code uniqueness and click analytics for the deep dive. In this flow, a technology name is mentioned only after the numbers and requirements ask for it.

Common mistakes

1. Jumping to technology. Naming Kafka before you know the throughput shows pattern recall, not reasoning.
2. Skipping estimates, or inventing precise numbers. Use round numbers, show the arithmetic and say they are assumptions.
3. Designing for planetary scale by default. Over-engineering is a failure of judgment. Start simple and scale where the numbers say so.
4. Silent thinking. The interviewer can only evaluate what they hear. Narrate your reasoning.
5. Ignoring non-functional requirements. A design without a stated consistency or availability goal cannot be judged.
6. Defending every choice. If the interviewer raises a flaw, acknowledge it and adapt; that is what a good design review looks like.
7. No failure discussion. Happy-path-only designs are incomplete.

Using the method at work

In a design review, the same steps become a document outline: goals and non-goals, scale assumptions, API, data model, architecture, alternatives considered, risks, rollout plan. Record the decisions in an ADR. The method is a thinking tool, not a script; if a step is irrelevant, say so and skip it.

A practice plan

1. Pick a familiar product (a chat app, a file upload service, a rate limiter).
2. Set a 45-minute timer and speak aloud, ideally to a colleague or recording.
3. Follow the eight steps and write the assumptions on paper.
4. Afterwards, list what you skipped or hand-waved and look it up.
5. Repeat with a different problem weekly, and rework an earlier one after learning a new concept such as caching.
6. Study one worked example end to end, such as the URL shortener design, then redo it from memory.

Checklist

• Requirements clarified, scope bounded
• Estimates with labelled assumptions
• API and entities sketched
• Simplest design first, components added for reasons
• One or two areas explored in depth
• Trade-offs stated with alternatives
• Failure modes covered
• Summary and next steps

Where to go next

Work through the URL shortener walkthrough as a model answer, read about what a solution architect does when these designs become real projects, or check your level with the skills assessment.