Interview Perspective

Clarify assigned-seat vs. general-admission inventory, whether multi-seat booking is in scope, whether payment is built or integrated, and whether high-demand/waiting-room behavior is expected. Then state the #1 invariant (no double-sell) and the close second (idempotent submission) before designing anything. See Problem Definition.

• What if the interviewer says 'assume general admission only'? — The per-seat atomic transition becomes an atomic bounded-decrement on a capacity counter — same concurrency-safety requirement, simpler mechanics, no per-seat identity to manage. See General-Admission Inventory.

An event owns seats (or a capacity counter for general admission). Each seat carries authoritative state. A hold is its own durable record — hold_id, event_id, owner, seat IDs, state, created_at, expires_at, version — not a flag on the seat. A booking references a hold and carries its own state plus a payment reference.

• Why not just put a 'held_by' column on the seat and skip a separate hold table? — You can fold hold fields onto the seat row for a single-seat model, but a separate hold record is what naturally supports multi-seat holds and gives you one clean idempotency key across several seats. See Seat State vs. Separate Hold Record.

Because expiry and payment coordination both need to distinguish 'this specific hold' from 'whatever hold currently occupies this seat.' Without an identity, a delayed operation from an old hold can't tell that the seat has moved on to someone else. See Hold Data Model.

• Where does this show up as a real bug if you get it wrong? — See Old Expiry Task Releases a Newer Hold.

Both requests attempt a conditional atomic transition (AVAILABLE → HELD) scoped to that exact seat. The database guarantees only one transition succeeds; the other affects zero rows and is rejected cleanly. See Atomic Seat Reservation.

• Optimistic concurrency or row-level lock — which would you pick, and why? — Depends on contention shape and how long the transaction needs to hold state. See Locking vs. Optimistic Concurrency.

Only if the conflict was transient (e.g. a version mismatch that has since resolved and the seat is genuinely still open). Retrying after losing a straight ownership race on a unique seat is not useful — that seat is gone. Distinguish the two before deciding to retry.

The second request carries the same idempotency key as the first. The system resolves it against the durable idempotency record and returns the existing hold rather than attempting a second reservation. See Hold Idempotency.

• What if the first request's response was lost, but it actually committed? — Same mechanism handles it — the retry discovers the existing hold via the idempotency key and returns it as if it were the original response. See Hold Created, Response Lost.

Attempt all three within a single transaction and verify all succeeded before committing any — otherwise a mid-sequence conflict leaves the user with an unwanted partial booking. Use a deterministic acquisition order across all requests to avoid deadlocks between two overlapping multi-seat attempts. See Multi-Seat Reservation.

• Why does lock order matter if each individual seat lock is still atomic? — Two multi-seat transactions can each hold one seat and wait on the other's, producing a deadlock, if they acquire seats in different orders. See Multi-Seat Deadlock.

Condition the release on the specific hold's identity and version, not just 'is this seat marked HELD.' A delayed task from an old, already-expired hold will find the seat's current hold_id no longer matches and will safely do nothing. See Expiry Generation Protection.

• What if two expiry workers process the same expired hold at once? — Both attempt the same conditional release; only one affects a row, the other is a safe no-op by construction. See Multiple Expiry Workers Running Concurrently.

Never take the seat back from whoever now legitimately owns it. Void or refund the late-successful payment, flag the original booking as a reconciliation exception, and notify the customer per policy (alternate seat, refund, or both). This is a defined policy decision, not an incidental edge case. See Payment/Hold Boundary and Payment Success, Seat Already Reallocated.

• Does a longer hold TTL solve this? — No — there's no TTL long enough to guarantee reconciliation always completes first. Design the late-success recovery path deliberately instead of trying to outrun the race with a bigger number.

No. The lock should only span the short transaction that creates or updates the hold record. Locking through the payment window would tie up database resources for minutes per in-flight checkout and serialize unrelated work. See Atomic Seat Reservation.

Deduplicate on the provider's event ID for duplicates. For out-of-order events, validate every incoming event against the current state's valid-transition table so a stale event can never regress an already-terminal payment or booking state. See Payment Webhook Duplicate and Payment Webhook Out of Order.

Cache against an explicit freshness target, not 'as aggressively as possible.' A stale-positive (shown available, actually taken) fails safely at reservation time. A stale-negative (shown taken, actually free) just costs a missed opportunity. Neither is a correctness bug as long as reservation always re-checks authoritative state. See Availability Cache Strategy.

Sharding by event_id isolates events from each other but doesn't help when the load is concentrated on a single event — the whole event still lands on one shard. Fix it with finer partitioning (event → section/block → seat) plus admission control specific to that event. See High-Demand Partitioning and Hot-Event Partition Saturation.

• Does finer partitioning have a cost? — Yes — multi-seat requests that span more than one partition become harder to reserve atomically. It's a genuine trade-off, not a free win.

Depends on the product's tolerance for user-facing wait and the cost of a rejected attempt. A waiting room paces admission ahead of the correctness-critical path; a queue defers processing; a straight reject is simplest but harshest under a real spike. See Queue vs. Reject vs. Waiting Room.

• Does an admission token guarantee the user gets a seat? — No — it only proves the right to attempt a reservation. Conflating admission with reservation is a common mistake. See Virtual Waiting Room.

Write the booking-confirmed event to an outbox table in the same transaction that commits CONFIRMED, so the event's existence is guaranteed by that same commit. A relay process publishes it asynchronously and may duplicate — every downstream consumer, including ticket issuance, must be idempotent. See Transactional Outbox and Ticket Issuance.

• Why not just call the ticket service directly from the booking transaction? — See Direct Publish vs. Outbox — a direct call can succeed while the DB commit fails, or vice versa; the outbox ties both to one atomic unit.

A stable business idempotency key on the ticket record (e.g. a uniqueness constraint on booking_id + seat_id) means the second attempt recognizes the existing ticket and no-ops rather than minting a duplicate. This matters especially wherever tickets are scanned for admission. See Duplicate Ticket Generation.

A reconciliation worker periodically queries payment-provider truth for bookings stuck past a threshold, applies the same guarded state-transition rules as the live path, and never confirms/cancels blind. Track both the oldest-pending-case age and total mismatch count as first-class metrics so a growing backlog is visible before it becomes a customer-facing problem. See Booking Reconciliation and Reconciliation Backlog.

Not for free — two regions must never independently believe they each own the same scarce seat. A single-writer-per-partition model with a defined failover path is the safer default; true active-active requires deliberate fencing design and is an advanced extension, not a starting point. See Single-Region Owner vs. Multi-Region Active-Active.

• What has to be true for failover to be safe? — Clear write-authority ownership per partition, and fencing that prevents the original region from resuming writes unexpectedly after it recovers. See Regional Failure.

Expired holds accumulate without being released, so the read model can show seats as unavailable that are actually free again — a UX/inventory-visibility cost. Reservation and confirmation logic must still treat expires_at as authoritative regardless of whether the worker got to it yet. Recover by processing the backlog in bounded batches once the worker is back, not one giant sweep. See Expiry Worker Down.

Cancellation must invalidate/revoke the issued ticket as part of the same workflow wherever ticket validity is checked at the point of use. A ticket already used before cancellation is processed is a policy exception (no refund, manual review) rather than a silent gap. See Cancellation & Refund and Cancellation vs. Ticket Use.

In scope: admission control sizing, finer partitioning for the hot event, cache capacity for the browse spike. Reasonable to flag as illustrative/out of exhaustive detail: exact numeric capacity targets, which should come from load testing the specific infrastructure rather than a rule of thumb. Say this explicitly rather than inventing a precise number under pressure.