The System-Design Interview Framework

A plausible diagram can still lose the round

The prompt is to design real-time presence for a team collaboration product. The candidate draws clients, WebSocket servers, a presence service, a cache, and a message bus. It is a plausible beginning. Then the interviewer adds two facts: some workspaces have 100,000 members, and a person removed from a workspace must stop seeing presence quickly.

Those facts do not ask for two more boxes. They reopen earlier decisions. A large workspace changes fan-out and partitioning. Rapid revocation changes the authorization path. If the candidate keeps extending the original diagram, the round may end with plenty of architecture and no coherent answer.

The system-design framework exists to prevent that failure. It is a way to move an incomplete prompt through a sequence of decisions while preserving time to test the result. More importantly, it tells you when to go back. A changed constraint should revise the design without resetting the entire conversation.

clarify -> scope -> estimate -> model -> design -> stress -> summarize

Chapter 74 described the evidence an interviewer can observe. This chapter puts that evidence on a clock. The chapters that follow will deepen each technical move; here, the skill is controlling the whole round.

Budget for decisions, not sections

In a 45–60 minute interview, the opening must be short enough to leave room for a credible design and its failure modes. A useful default is to spend the first five to eight minutes clarifying and scoping, a few minutes estimating only consequential dimensions, roughly ten minutes on APIs, data, and flows, and most of the remaining time on architecture and one serious deep dive. Protect the final few minutes for risks and a summary.

These are guardrails, not appointments. A storage-heavy prompt may require more estimation. An interviewer may move directly to consistency or failure. What matters is exit discipline: leave a phase when it has produced enough information for the next decision.

At the start of the round, make that intention visible:

I’ll first narrow the product and its dominant constraint. Then I’ll estimate only what shapes the design, model the critical read and write paths, and reserve time to stress the architecture before I summarize it.

This gives the interviewer a map and gives you permission to move on. It also makes a detour visible: if a discussion goes deep early, you can shorten a later phase deliberately instead of discovering at minute 48 that the design has never encountered failure.

Eleven moves, seven useful exits

The full sequence contains eleven moves:

1. Clarify the product.
2. Define the functional requirements.
3. Define the non-functional requirements.
4. Estimate scale.
5. Establish the APIs or events.
6. Model the data and its ownership.
7. Draw the high-level architecture and critical flows.
8. Identify bottlenecks.
9. Deep-dive into a critical component or path.
10. Address the relevant failure, security, observability, and cost concerns.
11. Summarize the decisions, trade-offs, and open risks.

You do not need to announce eleven headings. In conversation, related moves collapse into seven phases: clarify, scope, estimate, model, design, stress, and summarize. Each phase earns an exit.

The presence prompt shows how.

Clarify until you find the architectural hinge

“How many users?” is often too early. User count may matter, but it does not yet tell us which version of presence we are building or what harm matters. Better opening questions seek decisions:

Is presence limited to members of a workspace, and can users restrict who sees them? How stale may status become? Are very large workspaces common enough to shape the first design? Do we need history, or only current availability?

Suppose the interviewer answers that presence is visible only within a workspace, staleness of a few seconds is acceptable, a few workspaces are very large, and history is not required. The prompt now has a shape. Fresh-enough ephemeral state, authorization, and skewed fan-out matter. Historical analytics does not.

The exit condition is not “all questions answered.” Leave clarification when you can name the product variant and the fact most likely to bend the architecture. Chapter 76 develops this requirements work in detail.

Scope until the system has a promise

Turn the answers into a compact contract before drawing components:

Goal: workspace members can see fresh-enough availability and receive live changes.

In scope: device sessions, heartbeats, current status, workspace membership,
visibility rules, live subscriptions, and reconnect recovery.

Out of scope: chat history, calendar sync, attendance analytics, and federation.

Quality constraints: status may lag by a few seconds; membership changes must
stop unauthorized visibility quickly; large workspaces must not block heartbeat
acceptance; disconnects should decay safely to offline.

This is the first design artifact. It defines what success and failure mean. It also prevents scope from expanding invisibly. If the interviewer later asks for historical attendance, you can say why that is a new durable-data and privacy problem rather than quietly turning every heartbeat into an audit record.

Leave scope when the core workflow, dominant non-functional requirements, and intentional exclusions can constrain later choices. A long feature inventory does not improve the contract.

Estimate until a boundary moves

Now scale has something to act upon. Assume two million concurrently connected devices, each sending a heartbeat every 30 seconds. That is about 67,000 heartbeats per second before retries and peaks. The arithmetic suggests an ingestion path that partitions cleanly, but it does not yet prove that durable storage is difficult.

Workspace skew reveals the sharper pressure. A single status change in a 100,000-person workspace could create an enormous delivery burst if the system naively sends one event per member. Connection count, heartbeat rate, members per workspace, reconnect bursts, and acceptable staleness therefore matter more than total registered users.

Say what the estimates changed:

Heartbeat ingestion is high but regular. The less regular pressure is fan-out from very large workspaces, so I’ll keep ingestion independent from delivery and partition the delivery work by workspace or workspace shard.

Leave estimation when the important numbers have produced a bottleneck hypothesis, a capacity boundary, or a cost concern. If a number changes no decision, stop calculating it.

Model until every important truth has an owner

A component diagram says which boxes exist. A model says what those boxes are allowed to believe.

For this design, durable workspace membership and visibility policy belong to the workspace or identity domain. Device sessions identify live connections. Current presence is ephemeral state with an expiry, derived from heartbeats and explicit status changes. Subscription state tells the delivery plane which connection is interested in which workspace, but it is not authority to see that workspace.

The main operations follow from those truths:

• a client opens an authenticated session;
• a heartbeat refreshes current presence for that session;
• a workspace read returns an authorized snapshot;
• a subscription streams later changes to an authorized connection;
• a membership change revokes or expires affected subscriptions.

The distinction between authority and derived state is already doing design work. Losing ephemeral presence makes someone appear offline until the next heartbeat. Using stale membership can reveal status to the wrong person. Those failures deserve different recovery and urgency.

Leave modeling when you can trace the critical write and read paths, name the source of truth for each important decision, and explain what can be rebuilt.

Design the critical path before the catalog

The first architecture can now stay ordinary. Clients authenticate through a gateway and establish connections with WebSocket servers. A session service tracks which server owns each connection. The presence service accepts heartbeats and maintains expiring current state in a partitioned low-latency store. The workspace service remains authoritative for membership and visibility. Changes enter a delivery stream, and fan-out workers route them to authorized subscribers. Durable storage holds membership, policy, and audit-worthy administrative changes—not every heartbeat.

The boundaries have reasons:

• heartbeat acceptance does not wait for every recipient;
• fan-out can be partitioned and throttled without making presence writes unavailable;
• current status expires when a client disappears;
• durable policy is not replaced by whatever a client claims;
• connection state can be rebuilt after a WebSocket server fails.

Attach every additional component to a requirement or a discovered pressure. A queue is not evidence by itself. Here it earns its place by separating a regular ingestion workload from skewed delivery. A low-latency store earns its place because the product values current state and tolerates its loss, provided clients refresh it.

Leave the first design when another engineer can follow the critical path and explain why the main boundaries exist. Do not wait for the diagram to contain every production concern.

Stress the promise, then choose depth

Return to the interviewer’s two added facts.

First, the 100,000-person workspace. A partitioning scheme that assigns all work for a workspace to one worker preserves convenient ordering but creates a hot partition. Splitting delivery across workspace shards raises a new question: which ordering, if any, does the user need? Presence usually permits coalescing intermediate updates and keeping only the newest state per session. That relaxation makes batching and parallel fan-out possible. Clients can recover after a gap by fetching a fresh snapshot rather than replaying an unbounded history.

Second, rapid revocation. Authorizing only when the subscription opens leaves a removed member connected. The design needs either a revocation event sent to connection owners or short-lived authorization that forces timely renewal. The first improves revocation speed but depends on control-plane delivery; the second bounds stale access but adds repeated authorization work. A practical design may use both: push revocations for the normal path and retain a short expiry as the safety bound.

These pressures expose the best deep dive: fan-out under reconnect storms while permissions are changing. Follow it through behavior:

• WebSocket server failure causes clients to reconnect with jitter rather than all at once.
• Reconnecting clients fetch a current authorized snapshot before resuming updates.
• Heartbeats carry a session identity and increasing session sequence number; the service rejects a delayed update older than the last accepted sequence.
• Delivery coalesces superseded presence changes and applies per-tenant limits so one workspace cannot consume the entire fleet.
• Operators track heartbeat age, snapshot latency, fan-out delay, reconnect rate, hot partitions, and authorization rejects. These signals describe user-visible staleness and access failures better than CPU alone.
• Cross-region delivery, persistent connections, and large-workspace fan-out are explicit cost drivers; history remains excluded unless the product pays for a separate governed event path.

A stress pass is selective. A payments design will spend its time differently. Choose the failures and limits created by this system’s promise, then pursue one until the mechanism and trade-off are credible.

Leave stress when the design has encountered its dominant bottleneck, a real failure, and the most consequential security or privacy boundary—and when one critical path has been taken beyond component names into behavior.

Loop back without losing the story

A framework becomes useful when the prompt changes. Do not bolt the new fact onto the edge of the diagram. Name the invalidated decision and return to the earliest phase that must change.

If strict presence history becomes a compliance requirement, return to scope and modeling: ephemeral current state is no longer sufficient, retention and access rules become part of the promise, and an append-only governed record may be required. If status must be fresh within 100 milliseconds across regions, return to the non-functional requirements and estimates: network distance, regional ownership, and fan-out topology now dominate. If large workspaces disappear from the product, the elaborate sharded delivery path may no longer justify its complexity.

Useful recovery language is direct:

That constraint changes an earlier choice. I was treating current presence as disposable and eventually consistent. With an audit requirement, I need to separate the fast current-state path from a durable, access-controlled history path and revisit the retention cost.

Revision is not a concession. It shows that the architecture follows the problem rather than the candidate’s first diagram.

Finish with the design’s argument

When a few minutes remain, stop adding boxes. Give the interviewer the answer they should be able to carry into the debrief:

I optimized for fresh-enough workspace presence with rapid privacy enforcement. Membership and visibility policy are durable authority; current presence and connection routing are expiring, rebuildable state. Heartbeat acceptance is separated from skewed workspace fan-out so large tenants cannot block updates. The central trade-off is eventual consistency and coalesced delivery in exchange for a recoverable hot path. The largest remaining risks are reconnect storms, hot workspaces, delayed revocation, and cross-region delivery cost. I would validate the design with heartbeat age, authorized snapshot latency, fan-out delay, stale-presence duration, and revocation lag.

That summary does not repeat the diagram. It states the system’s argument: what it protects, which truth lives where, why the architecture has its shape, what it gives up, and where it may still fail.

Rehearse the exits

Practice the whole framework on one familiar prompt in 30 minutes. Do not aim for completeness. At the end of each phase, write the sentence that permits you to leave it:

Clarify: I know which version of the product I am designing.
Scope: I can state the promise, dominant constraints, and exclusions.
Estimate: the numbers have identified a pressure that changes the design.
Model: the critical paths and important truths have owners.
Design: the first architecture is explainable from those truths and pressures.
Stress: the promise has survived a bottleneck, a failure, and a boundary.
Summarize: the decisions, trade-off, risks, and validation signals are explicit.

Then change one constraint and give yourself five minutes to revise the answer. The useful question is not whether you touched every phase. It is whether the new fact changed the right earlier decisions while the design remained understandable.

Next, Requirements and Non-Functional Requirements slows down the opening phase and shows how a compact product contract creates real architectural pressure. For additional practice on the clock, use Timeboxing a 45–60 Minute Round.