A team is deciding whether to make 'reserve seat' in a ticketing checkout flow synchronous or route it through a queue for a downstream consumer to process. What criteria should drive that choice, and what's a concrete case where routing it through a queue would be the wrong call?

## The core criterion The core criterion is whether the caller needs the answer to decide what to do next, or whether the operation is a downstream **side effect** that the caller's own success doesn't logically depend on. This sounds simple but it's easy to get backwards, because async messaging's benefits — decoupling, buffering, horizontal scalability — are real and often make a team reach for a queue by default for anything that looks like background work. Seat reservation in a ticketing flow is exactly the case that exposes the flaw in that default: reserving a seat isn't a side effect of checkout, it's the **precondition** checkout depends on. If 'reserve seat' becomes 'publish a reservation-requested message and immediately return 202 Accepted,' the checkout flow has nothing true to tell the customer yet — it doesn't know if the seat is actually available, because the async consumer that will find out hasn't run. If checkout proceeds to charge the card optimistically on that 'accepted' response, you can end up charging a customer for a seat that turns out to be sold out, requiring a refund and an apology — a strictly worse failure mode than a synchronous check that just says 'sold out' immediately, before any payment is attempted. ## Why it is an architecture question The reason this matters at the architecture level, not just as a one-off implementation detail, is that mixing up 'hard precondition' with 'side effect' tends to happen precisely when a system is under load — the exact moment a team is most tempted to async-ify something to relieve pressure, and the exact moment getting it wrong is most costly, because that's also when contention for a scarce resource (the last few seats) is highest and double-booking risk is greatest. The general decision criteria are: - **(1)** does the caller's own next action require this result to be correct, not just 'eventually correct'? If yes, it needs a synchronous answer, even if that synchronous path is itself backed by fast, well-indexed infrastructure rather than a slow legacy call. - **(2)** Is strong consistency more valuable here than throughput smoothing? Seat availability is a classic scarce, contended resource where two requests racing for the same unit of inventory need a definitive winner and loser resolved immediately (via a database unique constraint, an optimistic-locking version check, or a distributed lock), not two requests both told 'accepted, we'll figure it out.' - **(3)** Is the operation naturally low-latency and low enough volume that synchronous handling doesn't create the load or availability problems async messaging exists to solve? A single row-level database check-and-update is fast; a request that fans out to five other services is not, and is a better async candidate — for the parts of it that aren't gating the immediate response. ## What choosing sync costs The trade-off in choosing sync here is that you give up the elasticity async gives you — a synchronous seat-reservation path has to be provisioned to handle its own peak load directly (connection pools, database write throughput, contention handling under a ticket-drop stampede), rather than letting a queue smooth a burst. This is a real cost: high-demand ticket releases are notorious for exactly this kind of synchronous contention meltdown, and the honest answer is that sync-for-correctness doesn't remove the scaling problem, it just means the scaling problem has to be solved with different tools: - optimistic concurrency control, - sharding inventory by section/row so contention is spread across many rows instead of one hot counter, - queuing customers into a virtual waiting room before they even reach the reservation endpoint, - or bounded-concurrency admission control — rather than papering over it with 'accepted' responses that turn out to be wrong. ## The failure modes Failure modes when this is gotten wrong in production are specific: 1. **Overselling** (multiple customers shown 'confirmed' or allowed to pay for the same seat because the authoritative availability check happened asynchronously and too late relative to the payment step), 2. a **support/refund burden** that's expensive and reputationally costly compared to a clean synchronous rejection, 3. and a **customer trust hit** disproportionate to the technical cause. The inverse failure — making something synchronous that should have been async — shows up as the checkout API blocking on non-critical work (an email service, a loyalty microservice) and failing the whole checkout because a side effect was slow, which is the original motivating problem async messaging solves. ## Where it shows up A well-known real-world instance of getting this right is how high-demand ticketing platforms architect seat/inventory holds as a synchronous, strongly consistent operation — typically a short-lived reservation lock tied to the checkout session, enforced at the database or cache layer with atomic compare-and-set semantics — while everything downstream of a successful purchase (confirmation email, calendar invites, loyalty point accrual, analytics) is fanned out asynchronously, because none of that downstream work can retroactively un-sell a seat that's already been correctly, synchronously confirmed as sold.