How to Approach System Design Questions

“Design a booking service” can lead to many different systems. A useful response begins by clarifying the users, important actions and constraints, then develops one request path before expanding it.

This method works in an interview and in real engineering discussions. The goal is to explain a coherent design and its trade-offs with explicit assumptions, rather than reciting a fixed list of components.

Identify who uses the system and the first capabilities. For booking, creation, cancellation and availability lookup may be in scope; payment or recommendations may be deferred deliberately.

Clarify latency, correctness, data retention, failure recovery and operating limits. If an answer is unavailable, state a reasonable assumption and explain its effect on the design.

Do not spend the entire discussion collecting trivia. Prioritise questions that change data ownership, workload, access or completion semantics.

Estimate average and peak request rates, read/write mix, payloads and retained data. Keep units visible and show the arithmetic. Use the capacity lesson to separate demand from assumed server budgets.

Draw one successful action with authoritative data, request and response behaviour. Include the permission boundary and the point where success is safe to report.

Choose a simple baseline that meets the assumptions. A database, application and object store may be sufficient before specialised layers are justified.

Use a booking-design discussion with limited time. Select a next step for each situation and build a short reasoning record.

The exercise is a guide to clarity, not a claim that every interviewer or project follows the same checklist.

If reads dominate, discuss query patterns and suitable caching with freshness. If writes compete for a unique slot, discuss the authoritative transaction rule. Depth should follow the problem.

Walk through one failure, such as a response lost after commit or a worker crash. Say what the user sees, which state remains and how retry or recovery works.

Explain the alternative you considered and why its cost is less suitable under the assumptions. Avoid promises such as unlimited throughput or perfect reliability without a supporting contract.

Restate the main flow, the required promises and the evidence still needed. Use labelled arrows and plain explanations before abbreviations.

The C4 model offers communication views, and AWS workload review guidance offers evaluation questions. Sources checked 6 October 2026. Use only the parts that help the actual discussion.

In practice, record unresolved risks and validation work. In an interview, explain how the design would evolve if a stated workload or requirement changed.

Clarify, estimate and trace a coherent request path. Choose components for their responsibilities, then examine a relevant failure and bottleneck.

State trade-offs and validation work openly. A clear argument with explicit assumptions is more useful than a diagram full of unexplained products.