Driving the Conversation

A design the interviewer can enter

Eighteen minutes into a news-feed design, the candidate is explaining queue partitioning when the interviewer asks, “What happens when an account with fifty million followers posts?”

The question could be a request for more queue detail. It could also be a warning that the candidate has missed the design’s hardest case. A candidate who treats the interview as a presentation will finish the prepared thought. A candidate who treats every interruption as an instruction will abandon the route and wait for the next prompt. Neither is leading.

A better response makes the change of direction explicit:

That is the case that breaks pure fan-out on write. Let me use it to choose
between write fan-out, read fan-out, and a hybrid, then I will trace the
resulting read path. I will keep queue mechanics at the level needed to make
that choice unless you want to return to them.

The interviewer can now see what the candidate inferred, what will happen next, and what has been postponed. The candidate has accepted the steering without surrendering the structure.

This is the communication problem particular to system design. The answer is too large to deliver in full, the interviewer has signals they want to probe, and time makes every deep dive an exclusion. Driving the conversation means creating enough structure for two people to change course without losing the design.

Open with a route that can be revised

Consider the prompt “Design a social news feed.” A weak opening begins naming services. Another weak opening asks a long list of questions whose answers never alter the architecture.

A useful opening exposes the decisions ahead:

I will start by bounding the product because ranking, freshness, and the
follower graph change the design. I am assuming users publish posts, follow
accounts, and load a home feed. Is that feed reverse chronological, or is
ranking part of the prompt? Are high-follower accounts in scope?

Once we fix those, I will estimate the read and write shape, choose a feed
generation strategy, draw the main paths, and spend the remaining time on the
constraint most likely to break the design.

Suppose the interviewer replies, “Keep ranking out of scope. High-follower accounts matter, and I care more about scale than API details.”

That answer has removed one subsystem, identified a stress case, and changed the time budget. The candidate should use all three:

Then I will optimize for a reverse-chronological feed under a skewed follower
graph. I will keep the API to the contracts the data path needs and reserve
the main deep dive for hot accounts and freshness.

The route is not a ceremonial agenda. It is a compact statement of priority. Because it names what will receive little time as well as what will receive depth, the interviewer can correct it before the candidate invests in the wrong answer.

Do not ask for permission at every transition. “Should I continue?” transfers the burden without presenting a choice. Offer direction where the alternatives would produce different evidence:

The next fork is useful: I can prove the feed-generation choice against the hot
account, or first establish the consistency users see after posting. I propose
the hot-account path because it decides the architecture.

This remains leadership. The candidate recommends a route while leaving the interviewer a meaningful way to redirect it.

Keep assumptions attached to consequences

System-design answers need assumptions, but an assumption ledger can become a second conversation that nobody maintains. Keep only assumptions with the power to change a decision, and state that decision in the same breath.

I am assuming feed reads outnumber post writes by roughly two orders of
magnitude. That makes predictable read latency worth some write amplification,
so I will begin with fan-out on write for ordinary accounts.

The number is modeled, not measured. Its job is to establish shape. If the interviewer gives a different workload, revise the decision instead of defending the estimate.

Some assumptions are product promises rather than traffic ratios:

• users should see their own post immediately, even if followers see it later;
• removing a follow should stop future feed materialization, while already cached entries may need explicit invalidation;
• private posts must not leak through stale feed entries;
• launch is regional, so global active-active writes are not yet a requirement.

Each sentence should eventually touch a read path, write path, placement choice, or failure behavior. “The system should be highly available and scalable” controls nothing until the candidate says which operation may fail, which state may lag, and what a user sees.

When an assumption changes, identify the affected decision:

Regional residency changes the earlier placement model. I can still use the
same feed-generation strategy within a home region, but cross-region follows
now need a product policy: replicate permitted post metadata into the
follower's region, or accept additional delay while fetching across the
boundary. I would not hide that choice inside the replication layer.

The phrase “that changes the earlier choice” is valuable because it gives the interviewer a visible dependency. It also prevents the common failure in which a candidate accepts a new constraint verbally while leaving the original diagram untouched.

Spend depth where the design can fail

After rough estimates, the news-feed candidate reaches three plausible strategies:

• fan out on write, which buys cheap reads by paying write amplification;
• assemble on read, which avoids materializing millions of follower entries but makes read latency and availability depend on more work;
• use a hybrid, treating ordinary and high-follower authors differently.

The important communication act is not listing the alternatives. It is choosing one and showing why this prompt deserves depth there:

I will choose the hybrid. Ordinary authors are materialized into follower
feeds; hot authors are stored once and merged during reads. The skewed
follower graph makes this boundary more consequential than the profile service
or post-creation API, so I will trace it through publish, backlog, read, and
failure.

Now follow the chosen design far enough to make the trade honest. A hot post enters the durable post store and publishes an event. The system records freshness metadata rather than enqueuing fifty million feed writes. When a follower loads the home feed, the read service merges the precomputed ordinary feed with recent posts from followed hot accounts, applies visibility rules, deduplicates, orders, and returns a cursor.

That solution avoids a write storm but introduces a variable read path. The candidate now owes answers about bounding the number of hot authors consulted, caching their recent posts, invalidating deleted or newly private posts, and degrading when the merge source is slow. Depth has exposed a cost that a box labeled “hybrid fan-out” concealed.

If the interviewer asks about queue partitions during this trace, answer the question and reconnect it to the decision:

I would partition ordinary fan-out work by author or fan-out job so a hot
author cannot monopolize every worker, and make each feed insertion idempotent
by post and recipient. The operating signal I care about is backlog age
translated into follower-visible staleness, not queue length by itself.

This is enough queue detail to establish isolation, retry safety, and a user-visible measure. Implementation trivia that does not change those properties can wait.

Use summaries as handholds, not announcements

A whiteboard accumulates stale arrows. Spoken assumptions are easy to forget. After a major choice, compress the current design into a few causal sentences:

So far, reads dominate writes and the follower graph is skewed. I chose
write-time materialization for ordinary authors and a read-time merge for hot
authors. That keeps ordinary reads predictable and prevents celebrity write
storms, at the cost of a more complex hot-author read path. The next unresolved
risk is privacy invalidation across both paths.

This summary lets the interviewer record evidence and challenge a contradiction. It also gives the candidate a clean place to propose the next move. A summary that merely repeats component names does neither.

Good summaries are selective. Use them when a decision closes a branch, when the interviewer changes a constraint, after a deep dive, and near the end. Summarizing every small step makes the conversation feel narrated rather than led.

Recover by repairing the model

Suppose the candidate has said that a short-lived authorization cache protects feed reads. The interviewer asks, “A user makes a private post public, someone shares it, then the author makes it private again. How quickly does the old feed entry disappear?”

The question reveals that a cache TTL is not a privacy design. A weak recovery adds a smaller TTL. Another weak recovery restarts the architecture. Repair the specific model:

My earlier answer treated visibility as a read-time cache concern, but we have
materialized feed entries that can outlive the permission change. I need a
visibility version on the post, invalidation to both materialized feeds and hot
post caches, and a final authorization check before serving. During
invalidation lag, the serve-time check protects privacy even if it costs an
extra lookup or a tightly controlled cache.

The correction propagates through stored state, caches, and the read path. It also creates an operational question: how to detect and bound invalidation lag. That is stronger evidence than pretending the original answer was close enough.

A compact recovery has four moves:

1. Name the broken product or system property.
2. Identify the assumption or model that caused it.
3. Change the affected path, source of truth, or invariant.
4. State the new cost or risk.

Apology is optional. Propagation is not. If the correction changes the source of truth, acknowledgment point, tenancy boundary, or consistency promise, walk that change through the rest of the design.

Protect the end of the round

Time control is visible prioritization. Around the midpoint, compare the route with what has actually been covered:

We have fixed the product scope, generation strategy, and main data paths. I
have about half the round left. I propose ten minutes on hot-author and privacy
failures, then I will cover operations and leave a few minutes to summarize.

This is more useful than announcing the clock. It names what will be protected and what may be compressed.

Do not spend the closing minutes touring every omitted topic. Finish the argument already made:

The design serves a reverse-chronological feed with read-heavy traffic and a
skewed follower graph. Ordinary authors use idempotent write fan-out; hot
authors use bounded read-time merge. That trades read-path complexity for
protection from extreme write amplification. The promises I would operate are
post durability, feed freshness, privacy after visibility changes, and
contained hot-author load. The remaining risks are hot-source availability,
invalidation lag, and the regional policy for cross-border follows.

The summary names scope, decisions, trade-off, promises, and unresolved risk. It does not claim that the design is complete. It makes the candidate’s judgment easy to evaluate.

Rehearse steering, not a script

Use a case from the next chapter or the casebook and record a 45-minute mock. Before listening back, mark only four moments:

1. the opening route;
2. the first interviewer interruption that should change depth or direction;
3. one assumption change that should alter the design;
4. the closing summary.

Then listen for the joins. Did the route contain a recommendation? Did the interruption change the plan, or only the next sentence? Did the revised assumption propagate into the diagram and failure behavior? Did the ending state a trade-off rather than inventory components?

For a resistant variation, have the interviewer introduce immediate permission revocation or regional residency after the candidate has committed to a single-region, materialized design. The purpose is not to produce a flawless answer. It is to practice keeping the design legible while its premises move.

The previous chapter made a migration inspectable by following authority through a changing system. A good interview conversation offers the same clarity under changing questions: the route remains visible, revisions have consequences, and both people know which decision is being made. Complete System-Design Transcripts lets you study that movement across full rounds.