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.