Establish what the system must do

For a fictional booking service, clarify who creates bookings, whether double-booking is allowed and how cancellations work. Separate essential behavior from optional features. Then ask about availability, latency and expected scale if those constraints matter to the exercise.

Employer guidance such as Amazon’s interview topics can indicate whether design is part of the process. It does not establish the exact question or grading rubric you will encounter.

Draw a minimal request flow

Start with the client, the service and a store for the authoritative booking record. Explain where input is checked and which operation must prevent conflicting reservations. Introduce a cache, queue or replica only when it solves a defined problem.

Design question Evidence of reasoning
What must be consistent? A rule for conflicting bookings
What can be delayed? A separate notification path
What happens on retry? A way to avoid duplicate effects
How is failure detected? Observable errors and recovery steps

This is an original discussion framework for an illustrative system. It is not a claim about a production architecture or an employer’s evaluation criteria.

Make estimates inspectable

If you assume 10 requests per second, label it as an interview assumption. Explain whether the figure is an average or peak and how it affects the decision. A correct multiplication cannot rescue an undefined workload.

Discuss the boundary where the current design stops being adequate. Perhaps one database is sufficient for the assumed load, but a regional outage changes the availability discussion. Avoid adding complexity before stating what it protects against.

Connect design to operation

A design must be deployable and diagnosable. Google’s SRE books provide primary material on operating services and reliability practices. Use the principles to ask how a person would detect, contain and recover from failure.

At broader scope, discuss migration, ownership and coordination across teams. At a smaller scope, explain the request path and data rules clearly. The career-path guide helps separate scope from title, while the reliability roles guide connects the design to operational work.