Ticket Booking Architecture Deep Dive

An event, a venue seat, and an event-specific sellable seat are three related but distinct concepts -- collapsing them makes it hard to sell the same physical seat across multiple events.

An Event carries the venue/show reference, start time, sale status, sale window, and inventory mode (assigned seating vs. general admission). A physical venue seat (section/row/number) is a stable fixture of the venue; the event-specific seat is the sellable unit for one particular event, carrying its own allocation state, pricing zone, and lifecycle -- the same physical seat is sold independently for each event held in that venue.

The seat map a user browses is a read model -- a cache, a read replica, or a materialized view -- deliberately kept separate from the authoritative reservation path.

Seat-map reads are scoped per event (and often per section, for large venues) so a cache key naturally isolates one event's traffic from another's. The read model can be a cache in front of the booking database, a dedicated read replica, or a periodically rebuilt materialized snapshot -- read replicas are one option among these, not a mandatory component.

A hold needs a durable identity of its own -- it is not simply a flag on the seat row. Without an identity, the system can't tell an old, delayed cleanup task apart from a legitimate new owner.

The hold is neither the payment nor the final ticket -- it's the durable record that a specific seat (or seats) is provisionally owned by a specific request, for a bounded time, pending payment resolution.

The core invariant: at most one live allocation -- an active hold or a confirmed booking -- can own a given seat for a given event at any time.

A user requesting A1, A2 and A3 together usually expects all-or-none -- and that semantic has to be enforced by the reservation operation itself, not assumed.

When all requested seats live in one transactional partition (one database, one shard), the baseline is: acquire or conditionally update every requested seat's row inside a single transaction, in a deterministic order (e.g. sorted by seat_id), verify every seat succeeded, and commit only if all did -- rolling back the whole attempt if any single seat fails.

Three mechanisms enforce the same reservation invariant -- the differences are about contention level and how long anything is held, not about which one is 'correct.'

A client can double-click Reserve, retry after a timeout, or refresh mid-request -- a stable idempotency key is what keeps these from creating a second hold.

A client-generated (or server-issued at seat-selection time) idempotency key maps to a durable uniqueness constraint. The first request creates the hold and stores a request fingerprint (event_id, requested seat IDs) alongside the key; a retried request with the same key resolves to the existing hold rather than attempting a second reservation.

An abandoned hold must reliably release its seats -- but the naive version of this check is unsafe, because it can release the wrong hold entirely.

Hold duration itself is a product decision -- shaped by checkout UX, payment method latency, event demand, and inventory scarcity. Minutes are common, but the architecture must not depend on any one universal duration.

Checking only the seat's state during expiry is not enough -- a delayed expiry task for an old hold can release a seat that now belongs to someone else entirely.

Concrete failure sequence: (1) Hold H1 owns seat A1 until 10:00. (2) H1 expires. (3) A1 becomes AVAILABLE. (4) User B acquires a new hold H2 on A1. (5) A delayed expiry task for H1 finally runs. (6) If that task's condition is only 'release A1 if state = HELD', it incorrectly releases H2 -- a hold that hasn't expired at all.

Expiry at scale is a real worker system, not a one-line cron query -- it needs indexing, batching, and safe concurrency across multiple worker instances.

Hold state, booking state, and payment state are three separate, bounded state machines -- forcing them into one giant enum produces invalid combinations.

Payment is a separate bounded context -- this module owns the booking/hold-side coordination around it, not payment internals.

Three outcomes matter to the booking side: known success, known failure, and unknown/timeout. A known failure fails the booking attempt and releases the hold. A known success confirms the booking, conditional on the hold still being valid (see Payment / Hold Boundary below). An unknown/timeout outcome does neither automatically.

A finite hold cannot be guaranteed to outlive every possible source of payment ambiguity -- provider outages, webhook delay, network partitions, or a reconciliation backlog can all outlast any hold duration you pick. The system needs an explicit policy, not a hope that the TTL is 'long enough.'

Baseline policy: (1) while the hold is valid and payment is unresolved, keep the booking PAYMENT_PENDING; (2) reconciliation resolves the provider's actual state; (3) if payment resolves to success while the hold still validly owns the seats, confirm atomically; (4) if the hold has already expired, released, or been reallocated to someone else by the time payment resolves, do not steal the seat back from whoever now holds it; (5) treat that specific case as an exception requiring void/refund or another policy-specific recovery; (6) reconciliation continues until the financial and booking states agree.

See Failure & Scale -> Payment Success After Hold Expiry and -> Payment Success, Seat Reallocated for the two concrete variants of this scenario and their recovery paths.

Where possible, the booking confirmation, the hold/seat state transition, and the outbox event are written together, inside one authoritative transactional boundary.

When booking, hold, and seat data share one transactional database, this is a single local transaction: booking -> CONFIRMED, hold -> CONFIRMED, seat allocation finalized, and an outbox row inserted -- all committed together or not at all. If this data is split across separate stores (for example, holds and payment state owned by different services), the same guarantee has to be achieved through a saga with its own compensations and a reconciliation backstop, rather than assumed.

Committing CONFIRMED to the booking database and publishing booking.confirmed to a broker are two separate operations -- and a crash between them silently drops the event unless that gap is explicitly closed.

Failure window: (1) the booking becomes CONFIRMED in the database; (2) the process crashes; (3) booking.confirmed is never published, so ticket issuance and notification never fire. The fix: write the booking state transition and a durable outbox row in the same database transaction; a separate relay publishes outbox rows to the broker and marks them published once acknowledged.

A confirmed booking produces one or more ticket artifacts/entitlements -- and issuance has to be idempotent, because the event that triggers it is delivered at-least-once.

The ticket issuance consumer reacts to booking.confirmed and generates the entitlement(s). A stable business idempotency key -- conceptually UNIQUE(booking_id, seat_id) or UNIQUE(booking_id, ticket_sequence) -- ensures a duplicate delivery of the same event recognizes the already-issued ticket and returns/no-ops rather than minting a second, independently usable one.

Reconciliation here covers more ground than payment lookups alone -- it's the sweep that catches every gap retries and holds' own expiry don't close.

Cancellation is its own short workflow, and it is not the same fact as a successful refund.

Baseline: validate the booking is still eligible for cancellation per product policy; transition the booking to a cancelling/cancelled state; invalidate or revoke the issued ticket where the product requires that (e.g. admission-scanning use cases); release the underlying inventory for resale if the product allows it; and initiate a refund.

A waiting room admits users into the booking path at a bounded rate before they can even attempt a reservation -- it does not itself reserve anything.

Sharding by event_id isolates ordinary events from each other well -- but it does not, by itself, scale one blockbuster event, because that single event still lands entirely on one shard.

A hierarchical strategy -- event -> section/block -> seat -- lets one hot event's load spread across multiple partitions internally, rather than concentrating entirely on a single shard. Deterministic seat-to-partition ownership (e.g. by section, or via consistent hashing for more even rebalancing as capacity changes) is one concrete way to implement this.

General-admission tickets are quantity inventory, not identity inventory -- the exact seat doesn't matter, only the count.

The model simplifies to available_capacity / reserved_capacity / sold_capacity for the event (or a ticket tier within it). Reservation becomes an atomic conditional decrement of a requested quantity q, rather than a per-seat conditional update -- conceptually the same invariant as e-commerce inventory reservation, applied to admission capacity instead of SKU stock.

Metrics should separate the read (availability) path from the write (reservation) path -- a spike in one is a very different incident from a spike in the other.

Invariants by entity