Build a system that sells finite inventory under high contention without overselling. The canonical examples are Ticketmaster (concert tickets) and Booking.com / Airbnb / Expedia (hotel rooms) — but the pattern generalizes to airline seats, restaurant tables, exam slots, ride dispatching, any limited-quantity-for-sale resource. The load-bearing technical reality is the same in all of them:

1. Inventory is finite — there are N tickets to this concert, M rooms at this hotel on this date.
2. Demand can dwarf supply — Taylor Swift Eras Tour onsale: 14M users showed up for a system sized for 1.5M; 3.5M Verified-Fan pre-registrations alone exceeded the previous all-time peak by 4×.
3. You can't oversell — selling the same seat twice destroys customer trust and triggers chargebacks / regulatory complaints / class actions.
4. You can't lose money on retries — when the user mashes "Pay" three times in 200ms because the network blipped, they must end up with one charge and one booking — not three of each, not zero of either.

The pattern that emerged across Ticketmaster, SeatGeek, StubHub, Booking.com, Airbnb, Expedia, and the broader ticketing/lodging industry is hold-then-confirm:

• User picks a seat / room → system places a soft hold with a TTL (5–15 min) — Redis SET NX PX is the dominant primitive.
• User completes payment within the hold window → system confirms via a strongly-consistent durable write that ties the booking commit, the idempotency claim, and the outbox publish into one transaction.
• Hold expires (TTL or explicit cancel) → seat returns to the pool automatically — no janitor job; Redis PX expiry does the work.