Trade-offs & Decisions

How should the system prevent two concurrent requests from both acquiring the same seat? All three options enforce the same invariant -- they differ in contention behavior.

Should the seat be held while the user completes payment, or must payment complete before anything is reserved?

When reservation demand exceeds safe capacity, three different responses are available -- and a backend message queue is not the same thing as a user-visible waiting room.

How stale can the seat map be, and what mechanism keeps it reasonably fresh? There is no single universal default TTL.

A decision matrix for picking a concurrency mechanism given the actual access pattern.

Multi-seat bookings add real atomicity complexity beyond the single-seat baseline -- worth calling out as its own decision rather than assuming it's free.

See Architecture Deep Dive -> Multi-Seat Reservation for the mechanics, and Failure & Scale -> Multi-Seat Partial Conflict / Multi-Seat Deadlock for the corresponding failure modes. The cross-partition case is a saga in the general sense -- a sequence of local holds with explicit compensation if a later seat in the set fails.

Should hold/allocation state be embedded directly on the seat row, or tracked in its own table?

Several mechanisms can implement durable hold expiry -- they trade precision against operational simplicity.

Sharding by event_id is a strong default for isolating unrelated events -- but it does not, alone, scale one blockbuster event.

Given a fixed admission rate into the booking path, how should the rate itself be chosen?

Admission capacity should be sized against the slowest correctness-critical dependency in the chain -- the booking database's safe write throughput, the payment provider's realistic capacity, and the expiry infrastructure's ability to keep up -- not simply the number of stateless application servers that can be spun up. Admitting faster than the payment provider can realistically process, for instance, just relocates the bottleneck downstream. The admission gate itself is a rate limiting problem -- the same token-bucket-style capacity reasoning applies, just enforced at the entrance to the booking flow rather than per API call.

Should clients poll the seat map, or should the server push updates?

Push is a UX enhancement, not a correctness improvement -- the reservation path is authoritative regardless of which one delivers the display update.

Some payment methods resolve synchronously; others are inherently asynchronous -- the confirmation path has to accommodate both without assuming one.

A valid checkout response can be PENDING when the chosen payment method resolves later via webhook or a redirect flow. The confirmation rule stays the same either way: before marking a booking CONFIRMED, the system must have durable evidence that payment actually succeeded and that the hold still validly owns the seats -- see Architecture Deep Dive -> Payment / Hold Boundary.

The Booking Service can explicitly orchestrate the correctness-critical path, while everything downstream of confirmation stays event-driven.

Reservation, payment coordination, and confirmation benefit from one explicit owner (the Booking Service) that can see and drive the whole sequence -- this is where correctness lives. Ticket issuance, notification, and analytics can react to booking.confirmed independently via choreography -- they don't need, and shouldn't need, to be coupled into the same synchronous path.

Publishing booking.confirmed directly after the DB commit is simpler, but leaves a real dual-write gap.

The baseline this module teaches is one authoritative write owner per event/partition -- multi-region active-active scarce inventory is a deliberate, advanced extension, not a default.