Teaching scenario: The room-booking example and all quantities below are hypothetical. Use them to practice reasoning, not as a sizing benchmark.
Begin with the outcomeAn interviewer asks you to design a meeting-room booking system. It is tempting to begin with a database, a cache, and a message queue. First describe what a successful interaction means: a person finds an appropriate room, reserves a time, and receives an accurate confirmation. That sentence exposes questions a component diagram cannot answer yet.
Does the system own the room inventory? Can two departments reserve the same room? Is a reservation confirmed immediately, or can it remain pending? Ask the questions that change the design. A long list of questions is less useful than a short explanation of why each answer matters.
Separate commitments from assumptionsFor this exercise, suppose the interviewer confirms that two successful reservations must never overlap for the same room. They also say the search page should feel responsive but may show slightly old availability. Record those as different commitments. Freshness for browsing and correctness for booking do not have to be identical.
Now suppose you assume that there are 8,000 booking attempts each day and that peak traffic reaches 15 attempts per second. Label the peak as an assumption to validate. The daily average is about 0.093 attempts per second, calculated as 8,000 divided by 86,400. Neither number tells you how much hardware to buy. They help identify the measurements and load tests you need next.
Write a small framing table before you draw:
Question
Working answer
Why it changes the design
What must stay true?
No overlapping confirmed bookings
The booking decision needs an authoritative conflict check
What may be temporarily old?
Search availability
Search can have a different freshness target
What happens under contention?
One request succeeds; the other gets a clear conflict
The API needs an explicit conflict outcome
What remains unknown?
Actual peak traffic and acceptable waiting time
Capacity and timeout choices remain provisional
Trace one important interactionFollow a single booking attempt from the person to the recorded result. Identify where identity is checked, which component makes the booking decision, and which record represents the result. Then ask what the person sees if the response disappears after the booking succeeds.
This flow gives your diagram a purpose. Every component should either support the interaction or satisfy a stated constraint. If you cannot explain why a component is present, postpone it until the requirement justifies it.
Make one decision visibleRecord a provisional choice: keep the authoritative booking decision in one service and validate its concurrency behavior before introducing a separate search projection. State the consequence: this gives the first version a clear ownership boundary, while search growth may later require a different read path.
AWS describes architectural decision records as a way to preserve a decision together with the context that led to it. That is the useful habit here: leave a reason someone can inspect, not just a final picture. Primary reference: AWS on architectural decision records.
Practice in two settingsFor an interview: Spend a few minutes framing the problem, then state the assumptions you will carry into the design. Ask a practice partner to change one constraint, such as allowing bookings across time zones. Explain which parts of your model need attention and which remain valid.
For a team: Use the printable Design Decision Worksheet before a review. Ask the product owner to check the outcome and the engineer responsible for operations to challenge the failure behavior. Do not require everyone to agree on a technology before they agree on the problem.
Your first deliverable is a defensible problem statement: who needs what, what must stay true, and which uncertainty is most likely to change the answer. Once that is clear, the component discussion becomes easier to evaluate.
Teaching scenario: The room-booking example and all quantities below are hypothetical. Use them to practice reasoning, not as a sizing benchmark.
Begin with the outcomeAn interviewer asks you to design a meeting-room booking system. It is tempting to begin with a database, a cache, and a message queue. First describe what a successful interaction means: a person finds an appropriate room, reserves a time, and receives an accurate confirmation. That sentence exposes questions a component diagram cannot answer yet.
Does the system own the room inventory? Can two departments reserve the same room? Is a reservation confirmed immediately, or can it remain pending? Ask the questions that change the design. A long list of questions is less useful than a short explanation of why each answer matters.
Separate commitments from assumptionsFor this exercise, suppose the interviewer confirms that two successful reservations must never overlap for the same room. They also say the search page should feel responsive but may show slightly old availability. Record those as different commitments. Freshness for browsing and correctness for booking do not have to be identical.
Now suppose you assume that there are 8,000 booking attempts each day and that peak traffic reaches 15 attempts per second. Label the peak as an assumption to validate. The daily average is about 0.093 attempts per second, calculated as 8,000 divided by 86,400. Neither number tells you how much hardware to buy. They help identify the measurements and load tests you need next.
Write a small framing table before you draw:
Question
Working answer
Why it changes the design
What must stay true?
No overlapping confirmed bookings
The booking decision needs an authoritative conflict check
What may be temporarily old?
Search availability
Search can have a different freshness target
What happens under contention?
One request succeeds; the other gets a clear conflict
The API needs an explicit conflict outcome
What remains unknown?
Actual peak traffic and acceptable waiting time
Capacity and timeout choices remain provisional
Trace one important interactionFollow a single booking attempt from the person to the recorded result. Identify where identity is checked, which component makes the booking decision, and which record represents the result. Then ask what the person sees if the response disappears after the booking succeeds.
This flow gives your diagram a purpose. Every component should either support the interaction or satisfy a stated constraint. If you cannot explain why a component is present, postpone it until the requirement justifies it.
Make one decision visibleRecord a provisional choice: keep the authoritative booking decision in one service and validate its concurrency behavior before introducing a separate search projection. State the consequence: this gives the first version a clear ownership boundary, while search growth may later require a different read path.
AWS describes architectural decision records as a way to preserve a decision together with the context that led to it. That is the useful habit here: leave a reason someone can inspect, not just a final picture. Primary reference: AWS on architectural decision records.
Practice in two settingsFor an interview: Spend a few minutes framing the problem, then state the assumptions you will carry into the design. Ask a practice partner to change one constraint, such as allowing bookings across time zones. Explain which parts of your model need attention and which remain valid.
For a team: Use the printable Design Decision Worksheet before a review. Ask the product owner to check the outcome and the engineer responsible for operations to challenge the failure behavior. Do not require everyone to agree on a technology before they agree on the problem.
Your first deliverable is a defensible problem statement: who needs what, what must stay true, and which uncertainty is most likely to change the answer. Once that is clear, the component discussion becomes easier to evaluate.
Put this lesson to work.
Download the PDF worksheet to use in your next practice session or design review. It is free with your AI Architect Circle account.