Which operations in a ticketing system need strong consistency and which are correct with eventual consistency?

What is being tested

Whether you decide consistency per operation rather than choosing one model for the system, and whether you can justify each choice from the cost of being wrong.

The operations

Strong consistency required:

• Seat allocation. A hard cross-row invariant — two people must not hold the same seat. This needs a conditional write or serialisable isolation, and it is the one place where the cost is unavoidable.
• Payment capture. Money moved once, no duplicates. Idempotency keys plus a durable record before the side effect.
• Reservation expiry. A held seat released exactly once, or it is either double-sold or lost.

Eventual consistency correct:

• Event search and browse. A listing seconds stale harms nobody. Served from an asynchronously updated index.
• "Only 12 tickets left" indicators. Approximate by design. Exact counts here would be enormously expensive for a number that is decorative.
• Recommendations and related events.
• Analytics, reporting, and the artist's dashboard.
• Email confirmations, which are asynchronous by nature.

Session guarantees sufficient — the middle ground people forget:

• The user's own order history needs read-your-own-writes, not global strong consistency. They must see the ticket they just bought; they need not see someone else's purchase instantly.
• Availability counts during a browsing session need monotonic reads — the number should not go up and down as requests hit different replicas, which looks broken even when both values are legitimate.

The decisive reasoning

Asymmetry of failure cost. A false "sold out" is a recoverable annoyance — the customer retries or comes back. A double-sold seat is unrecoverable: two people arrive at the venue and one is turned away, with a refund, a complaint and a reputational cost.

That asymmetry is what decides CAP questions in practice, and it decides them per operation rather than per system.

The shape this produces

Search is eventually consistent; the commit is strongly consistent and authoritative.

Search shows possibly-stale availability. At the moment of commitment, the seat is allocated with a conditional write against the authoritative store. If it fails, the user is told honestly and offered alternatives.

Never make search strongly consistent — enormously expensive and unnecessary. Never let the commit trust search — that is the correctness bug.

What a strong answer adds

The high-demand case. For an on-sale where demand vastly exceeds supply, the honest architecture is a queue or virtual waiting room: admit users at a rate the allocation system can serve, show a position, and keep the strongly consistent component inside its capacity. That converts an outage into a queue, which customers understand, and it preserves the transaction rather than losing it.