The senior system design interview

Start by agreeing on the essential user flows, their priority, and measurable constraints. Separate functional requirements, such as reserving a seat, from nonfunctional requirements, such as reservation latency, availability, and acceptable data loss. If a target is missing, propose an assumption and ask the interviewer to confirm it.

Name the linchpin: the constraint or invariant that determines the design. For ticket booking, it may be preventing two successful reservations for the same seat during a burst. For a feed, it may be serving readers efficiently despite highly uneven follower counts.

At mid-level, clarifying core functions and scale with some prompting can meet the bar. A senior prioritizes requirements, quantifies important nonfunctional requirements, and identifies the hard part. Staff-level framing goes further by finding the crux quickly, cutting scope aggressively, and stating what does not need to scale.

Propose a short agenda: requirements, end-to-end design, focused deep dives, then failure handling and a recap. Build a complete baseline before spending most of the session on one component. At senior level, you should drive most of the discussion and select at least one deep dive because it matters to the requirements.

For an illustrative 45-minute interview, you might use 5–8 minutes for framing, 10–12 for the baseline design, 15–18 for deep dives, and the remainder for operations and synthesis. This is a planning aid, not a scoring rule. Adapt to the actual format and interviewer direction.

A mid-level candidate may rely on the interviewer to choose deep dives. A senior proposes where to go next and explains why. At staff level, the candidate drives nearly all of the discussion, with the interviewer acting more like a design peer.

A senior engineer system design answer should reach a coherent end-to-end design quickly. Show the APIs, important records and keys, request paths, state transitions, and source of truth. Every component should have a reason tied to a requirement.

Walk through one important write and one important read. Explain when the caller receives success, what has become durable at that point, and how downstream views become visible. A diagram containing a load balancer, cache, queue, and database is not complete unless those interactions make sense.

At mid-level, a complete simple design with light nudges can be sufficient. At senior level, the baseline should be complete quickly and use well-chosen components. At staff level, expect an especially minimal design organized around the crux.

Technical depth usually escalates from what a component does, to why you chose it, how it works, what happens under stress or failure, how much it can handle, and what you would change next. Naming a technology is only the beginning.

The rubric expects mid-level depth around “how” on core components. A senior should handle “what if” and “how much” probes in about two areas. Staff-level depth reaches capacity limits and next-step evolution in several areas.

Use estimates to answer a decision, not to fill a worksheet. With an explicitly assumed 10 million requests per day, average traffic is about 116 requests per second. An assumed 10× peak gives about 1,160 requests per second, but neither number describes contention on a single hot key.

A senior answer connects requirements to alternatives and then commits. “SQL versus NoSQL” is not a useful debate by itself. “These records need an atomic update together, and the access pattern fits indexed relational queries” is a defensible reason to start with a relational database.

Use a compact structure: requirement, options, choice, cost, and revisit trigger. Avoid listing every possible technology or qualifying every decision until nothing is decided. Keeping the system simple is part of the evaluation.

At mid-level, reasonable choices and trade-offs stated when asked may meet the bar. Seniors volunteer the important trade-offs and decide. Staff candidates are expected to decide crisply and remove complexity that does not serve the crux.

Do not wait for “What if this fails?” Trace the critical path and identify its main failure modes. Explain timeouts, bounded retries, overload behavior, duplicate delivery, partial completion, and recovery. State which operations must reject or pause rather than return an unsafe success.

Connect monitoring to user outcomes and invariants. Request latency alone will not reveal a growing notification backlog, a stuck payment reconciliation process, or reservations that never expire. Include cost and growth where they affect the design, such as retention, replication, or high fan-out.

Mid-level candidates may cover common failures after prompting. Seniors proactively cover the main failures and monitoring. Staff-level designs incorporate failure behavior, rollout, and service objectives from the start.

Make the design easy to follow. Label arrows, distinguish synchronous calls from asynchronous events, and keep one consistent source of truth for each important entity. Explain a component at the depth needed for the decision, then invite or follow deeper probes.

Treat hints as collaboration. If the interviewer exposes a flaw, acknowledge it, repair the design, and explain the consequences. If you do not know a product detail, say so and reason from the guarantee you need rather than inventing behavior.

Clear and receptive communication is the mid-level baseline. Senior communication should also be concise and collaborative. Staff-level communication is peer-level and high bandwidth, without unnecessary introductory explanations.

Begin with an explicit invariant: a seat must not have overlapping valid reservations. Clarify hold duration, purchase confirmation semantics, and whether search results may be stale. A cached seat map can support browsing, but the reservation operation must validate authoritative inventory.

Start with a transactional model for seats, holds, and bookings. Explain how a conditional update or transaction checks availability and creates a hold atomically. Define expiry using authoritative database state and time; a background cleanup job should not be the only thing that makes an expired hold reclaimable.

Choose two deep dives: inventory contention and payment uncertainty. For a payment timeout, do not assume failure. Define durable workflow state, retry-safe payment requests where supported, reconciliation, and what happens if payment succeeds after the hold can no longer be confirmed.

Practice unfamiliar prompts under a time limit, then review the recording or diagram against the seven rubric dimensions. Ask whether the design was complete, whether you selected the right hard problem, and whether important decisions were justified without prompting.

Use contrasting problems rather than memorizing one architecture. A notification system exercises delivery and retries; ticket booking exercises contention; a distributed cache exercises ownership and failover. Revisit a prompt with a changed requirement to test whether you understand the design rather than remember it.

After each practice session, choose one specific improvement. “State the write invariant before choosing storage” is actionable. “Get better at distributed systems” is not.