Teaching scenario: A small organization is replacing its meeting-room booking application. The requirements, observations, and options below are hypothetical.
Make the comparison fairA design review becomes difficult when one option is judged on simplicity and another on an imagined future scale. Put the same problem in front of every alternative. In our example, the first release serves one organization, confirms bookings interactively, and must prevent overlapping confirmed reservations for a room. Search freshness is less strict than booking correctness.
The team is considering two designs. Option A uses one application service and an authoritative transactional store. Option B adds a separate availability search projection, a reservation service, and asynchronous updates between them. Neither label establishes correctness. Each option still needs an explicit booking rule and evidence that concurrent requests respect it.
Reject violations before scoring preferencesStart with requirements that an option must satisfy. If a proposal confirms a booking solely from a stale search result, it fails the stated overlap rule unless another control prevents the conflict. A high score for developer experience cannot compensate for that failure.
After checking the hard constraints, compare preferences. Keep the table short enough that a reviewer can see what is known, assumed, or untested.
Criterion
Option A
Option B
Evidence to gather
Booking correctness
One proposed decision owner
Reservation service must remain authoritative
Concurrent attempts for the same room and time
Search freshness
Reads the chosen store or cache
Projection may lag
Delay measurements and user-facing stale-result behavior
Operational work
Fewer proposed moving parts
More state transitions to observe
Deployment, recovery, and support walkthrough
Future search growth
Revisit when measurements require it
Search can evolve separately
Representative queries and measured demand
These are descriptions of the hypothetical designs, not universal rankings of architectural patterns. An experienced team or a different workload could change the result.
Choose with a reason and a limitA reasonable provisional decision is to start with Option A, given the stated first-release scope and the team's limited operating capacity. That is a recommendation for this scenario. It is not a claim that one service is always better than several.
Write the decision in plain language: “We will keep booking ownership in one service for the first release. We will validate concurrent booking behavior and measure search latency before deciding whether a separate search projection is justified.” Then record the trade-off: search and booking share more infrastructure initially, so growth could create pressure that requires a later split.
The useful part of an architecture decision record is the reasoning and consequences that remain after the meeting. AWS's ADR process describes those elements and a lifecycle in which a later accepted record can supersede an earlier decision. Primary reference: AWS ADR process.
Define the reconsideration triggerAvoid “we will scale later” as the entire plan. Choose a testable trigger. For this exercise, the team might agree to revisit the read path when its measured search latency repeatedly misses the agreed target under representative load, after straightforward query improvements have been evaluated. The actual target belongs to the team's requirements; do not borrow a number simply because it sounds impressive.
Assign someone to collect the evidence. A trigger without an owner often becomes a sentence nobody acts on. Keep the old decision available when the new evidence arrives so reviewers can distinguish a changed requirement from an implementation defect.
Practice the explanationFor an interview: Explain both alternatives in roughly the same amount of detail. Say which constraint drives your recommendation and what new information would make you change it. Invite the interviewer to challenge that condition.
For a team: Bring one page containing the options, hard constraints, evidence gaps, recommendation, and reconsideration trigger. Ask reviewers to improve the evidence or challenge an assumption. A useful review ends with a decision that can be tested, not just a collection of preferences.
Teaching scenario: A small organization is replacing its meeting-room booking application. The requirements, observations, and options below are hypothetical.
Make the comparison fairA design review becomes difficult when one option is judged on simplicity and another on an imagined future scale. Put the same problem in front of every alternative. In our example, the first release serves one organization, confirms bookings interactively, and must prevent overlapping confirmed reservations for a room. Search freshness is less strict than booking correctness.
The team is considering two designs. Option A uses one application service and an authoritative transactional store. Option B adds a separate availability search projection, a reservation service, and asynchronous updates between them. Neither label establishes correctness. Each option still needs an explicit booking rule and evidence that concurrent requests respect it.
Reject violations before scoring preferencesStart with requirements that an option must satisfy. If a proposal confirms a booking solely from a stale search result, it fails the stated overlap rule unless another control prevents the conflict. A high score for developer experience cannot compensate for that failure.
After checking the hard constraints, compare preferences. Keep the table short enough that a reviewer can see what is known, assumed, or untested.
Criterion
Option A
Option B
Evidence to gather
Booking correctness
One proposed decision owner
Reservation service must remain authoritative
Concurrent attempts for the same room and time
Search freshness
Reads the chosen store or cache
Projection may lag
Delay measurements and user-facing stale-result behavior
Operational work
Fewer proposed moving parts
More state transitions to observe
Deployment, recovery, and support walkthrough
Future search growth
Revisit when measurements require it
Search can evolve separately
Representative queries and measured demand
These are descriptions of the hypothetical designs, not universal rankings of architectural patterns. An experienced team or a different workload could change the result.
Choose with a reason and a limitA reasonable provisional decision is to start with Option A, given the stated first-release scope and the team's limited operating capacity. That is a recommendation for this scenario. It is not a claim that one service is always better than several.
Write the decision in plain language: “We will keep booking ownership in one service for the first release. We will validate concurrent booking behavior and measure search latency before deciding whether a separate search projection is justified.” Then record the trade-off: search and booking share more infrastructure initially, so growth could create pressure that requires a later split.
The useful part of an architecture decision record is the reasoning and consequences that remain after the meeting. AWS's ADR process describes those elements and a lifecycle in which a later accepted record can supersede an earlier decision. Primary reference: AWS ADR process.
Define the reconsideration triggerAvoid “we will scale later” as the entire plan. Choose a testable trigger. For this exercise, the team might agree to revisit the read path when its measured search latency repeatedly misses the agreed target under representative load, after straightforward query improvements have been evaluated. The actual target belongs to the team's requirements; do not borrow a number simply because it sounds impressive.
Assign someone to collect the evidence. A trigger without an owner often becomes a sentence nobody acts on. Keep the old decision available when the new evidence arrives so reviewers can distinguish a changed requirement from an implementation defect.
Practice the explanationFor an interview: Explain both alternatives in roughly the same amount of detail. Say which constraint drives your recommendation and what new information would make you change it. Invite the interviewer to challenge that condition.
For a team: Bring one page containing the options, hard constraints, evidence gaps, recommendation, and reconsideration trigger. Ask reviewers to improve the evidence or challenge an assumption. A useful review ends with a decision that can be tested, not just a collection of preferences.