System design interviews and trade-offs

System design conversations are easier when they begin with a question instead of a diagram. What must the service do first? Who depends on it? Which failure would be most damaging? These questions reveal priorities before implementation details start to multiply.

Trade-offs are the substance

A practical answer states what it optimizes and what it gives up. A modest storage choice may reduce operational work while limiting scale. A cache may improve response time while introducing freshness questions. Neither choice is automatically correct; the explanation is what makes the choice reviewable.

Use a visible sequence

Describe the request path, then the data that must persist, then the boundary where load or failure changes the design. Keep the first version small. Invite a question about one weak point and update the proposal in response. This shows how you work with uncertainty rather than pretending it is absent.

• Clarify the users and the success condition.
• Separate must-have behavior from a later improvement.
• Say what you would measure after release.
• Explain the failure mode you would handle first.

Preparation is useful when it creates a habit of asking better questions. It becomes less useful when it turns every interview into a memorized performance.

Keep the context, make the decision visible, and leave a useful next step.