The clock starts before the diagram
A system design interview is a compressed design review, not a test of how quickly you draw a cache, queue, and database. The interviewer watches how you turn an underspecified request into a bounded problem, make assumptions visible, and choose worthwhile detail. A prompt is a starting point, not a specification.
A chat service, file-storage product, ride dispatch system, or feed can require radically different architectures. A small internal chat tool differs from a consumer product with millions of active users in traffic, privacy, retention, and delivery guarantees. Identify the decisions that shape those differences and take a defensible path through the available time.
Forty-five minutes makes detours costly: fifteen minutes listing API endpoints leaves little time for failure handling, while sharding before agreeing on reads and writes becomes technical-vocabulary theater. Move from intent to scope, then to a coherent first design and pressure points that reveal judgment.
Requirements turn ambiguity into scope
Separate functional behavior from system properties. Behavior is what a user or service can do: post a message, upload a file, retrieve a timeline, reserve inventory, or receive a notification. Properties are the conditions it must meet: traffic, latency, availability, durability, ordering, data residency, and budget. These change the architecture.
Ask questions only when they remove a design branch. For a URL shortener: can links be edited, must redirect analytics be real time, and are custom aliases supported? For a payment-like ledger: may users see stale balances, and must duplicate requests be rejected? For video: does scope include live delivery or only upload and playback? If answers are unavailable, state assumptions: “I will optimize for read-heavy traffic, accept eventual consistency for counters, and treat deletion as a durable user request.” This lets the interviewer redirect early and ties caching, replication, queues, and storage to needs rather than defaults.
A compact opening frame is:
- Name the primary user action and highest-value read path.
- Set an order-of-magnitude traffic estimate and data-growth horizon.
- Identify one or two correctness guarantees that cannot break.
- Exclude adjacent features that would consume the session without changing the core architecture.
Excluding search, billing, recommendation ranking, or a full abuse-review workflow is not evasive; it preserves a useful boundary and shows the system can be extended later without solving an entire company in one session.
A familiar architecture can still fail
Client, load balancer, stateless service, cache, database, and asynchronous worker is a reasonable opening for many prompts. It becomes weak when the diagram is the answer. Explain data flow, ownership boundaries, and why each component exists.
For a photo-sharing feed, a cache before a database does not answer whether entries are assembled when a creator publishes or when a reader opens the app. Fan-out on write gives fast reads for ordinary accounts but causes a large write burst for huge audiences. Fan-out on read reduces that burst but can make a request perform joins and ranking work. A hybrid for high-follower accounts is often sensible, but creates two delivery paths, reconciliation concerns, and different freshness behavior. That trade-off says more than the cache.
Likewise, a queue smooths bursts but adds delay and requires idempotent consumers; replicas increase read capacity but can return older data; partitioning spreads writes but a poor key creates hot shards or expensive cross-partition queries. Each component should address a concrete pressure: contention, latency, durability, isolation, geographic reach, or operational recovery.
Do not assume every service needs independent deployment or that microservices are scale’s natural destination. For a bounded prompt, a modular monolith with a primary data store may be the cleaner first design. Component count is not the goal; workload-matched boundaries and failure reasoning are.
The 45-minute sequence exposes judgment
Minute marks are guardrails, not a script. They prevent spending the session on a diagram and discovering at the end that reliability or cost was never discussed.
- Minutes 0–5: frame the problem. Restate the goal, ask scope-changing questions, declare assumptions.
- Minutes 5–12: map the user and data paths. Identify core reads, writes, entities, and request order.
- Minutes 12–20: draw a modest first architecture. Show only services and stores needed for the main path.
- Minutes 20–32: deepen the riskiest path. Cover schemas, partitioning, cache behavior, queue semantics, or consistency where it matters most.
- Minutes 32–40: test under stress. Address retries, overload, partial failure, recovery, and one growth scenario.
- Minutes 40–45: recap choices and alternatives. Name accepted trade-offs and the signal that would trigger redesign.
Follow the prompt rather than a memorized detail order. Booking may hinge on preventing double allocation during bursts; metrics pipelines on backpressure and late events; collaborative editing on conflicts and offline synchronization. Spend detail where a wrong decision damages trust or behavior.
If an interviewer adds tenfold traffic, a regional outage, strict deletion, or audit records, treat it as a change request, not proof that the first design failed. Explain the affected part, changed guarantee, and what you would add or replace. Calm revision is stronger than defending a fixed diagram.
Depth should follow the interviewer’s signals
Detail should vary by interviewer. A product-focused engineering manager may emphasize user behavior, delivery risk, and team ownership; a distributed-systems specialist may probe replication lag, leader election, or retry safety; a platform interviewer may care about tenancy, observability, and operational controls. Keep the first design legible to all, then follow the questions.
Listen to their nouns. “What happens if this request is sent twice?” invites idempotency keys, deduplication windows, and side-effect boundaries. “How do you know the queue is falling behind?” calls for queue depth, age of the oldest message, consumer throughput, and load shedding. A disproportionately noisy customer calls for rate limits, partition hot spots, and isolation, not generic autoscaling.
State choices so they can be challenged: “I would use a relational database because reservations require transactions across inventory and booking records,” not “SQL is reliable.” Precision means naming the needed property and accepted cost, not a vendor.
Finish the main thought before adding branches. Build one credible route from request to stored state to response, then add exceptions such as a cache miss, failed payment authorization, delayed event, replica lag, or regional failover. This keeps the conversation intelligible while showing range.
Numbers prove the design exists
Back-of-the-envelope math tests whether capacity claims fit the architecture. Assumptions need only connect demand to a resource constraint. At 10,000 writes per second, with three downstream events per write, queues and consumers must handle roughly 30,000 events per second before retries. If a 100 KB request is made by 50,000 users each second, outbound bandwidth deserves attention before database tuning.
Use numbers to find the limiting path and choose a response. Read-heavy traffic may need caching and replicas with stated staleness tolerance; write-heavy traffic may need partitioning by tenant, account, or object identifier; large media workloads may place bytes in object storage and a content delivery network while the application database stores metadata. Preserve the opening requirements.
Quality has multiple axes: low median latency does not offset lost writes; high availability does not excuse duplicate money movement or ignored deletion; cheap storage does not fix undefined recovery. Name the relevant metric: p95 or p99 latency, error rate, durable-write acknowledgement, replication lag, recovery point objective, recovery time objective, queue age, or cost per request.
Avoid false precision. A claimed 92% cache hit rate without a workload model invites doubt. Instead, say the cache targets repeated reads and telemetry will track hit rate, eviction churn, origin load, and stale-response frequency. That distinguishes a hypothesis from a verified property.
Growth shifts the failure boundary
Initial designs usually fail when a hidden assumption stops holding: one tenant dominates database writes, queue consumer lag delays work past its useful window, or invalidation after a popular-object change creates stale cache responses. Scale moves the difficult problem.
Describe stages. First, a primary database with replicas and backups may suffice. Next, partition for write capacity or data isolation. Later, add regional routing for latency or resilience. This shows restraint and acknowledges that changing a partition key, splitting tenant data, or moving from one region to several cannot be flipped during an incident.
As systems grow, retries need bounded attempts and jitter to prevent retry storms; jobs need dead-letter handling and safe replay; schema changes need old/new client compatibility; and dashboards must reflect user impact, not only machine health. A healthy database does not help if an expired certificate, overloaded worker pool, or blocked third-party API stops the core action.
Do not promise zero downtime or perfect consistency at every scale. Identify the prompt’s most important failure and its control: reservation expiry, idempotency record, immutable event log, cross-region replica, circuit breaker, manual reconciliation path, or clear degradation mode. The right control depends on the damage of being wrong.
Practice the handoffs, not memorized diagrams
Practice like the interview: pick a prompt, set a timer, sketch the main path, and record the explanation. Review transitions that hide assumptions: a queue without a producer contract, cache without invalidation, or database without a data model. Spoken practice exposes these gaps better than polished documents.
After each session ask: Did it begin with user and scope? Did every major component have a reason? Did it quantify one demand path, explain one failure mode and trade-off, and end with what changes at higher scale? This is more useful than judging how much infrastructure appeared.
Practice midstream changes. Have a peer add legal retention, a much hotter tenant, offline clients, a partial regional outage, or an unexpected cost ceiling after the first diagram. The goal is not memorizing variants, but learning the handoff from requirement to decision and from decision to consequence.
Study technologies by behavior: how caches serve stale data, queues redeliver messages, transactions protect state transitions, and replicas lag. Product names can show familiarity, but explain the primitive first and vendor second.
A usable design leaves a trail
A persuasive answer leaves a trace from user need to engineering choice. The interviewer should identify which workload, guarantee, or failure each component addresses, and what the design does not yet solve and why that omission is acceptable at this stage.
The forty-five-minute structure keeps the hard work visible: define scope, choose a first design, test it with numbers and failure, and revise it without drama. A clean diagram helps; a clear chain of reasoning makes it credible.