Marketplace
Booking System Without Double-booking
Reservation system that never double-books inventory under concurrent demand.
Scale to anchor on
Millions of listings, tens of thousands of concurrent reservation attempts during peak (sale launches, popular cities), strict no-double-booking.
Requirements
Functional
- Hold inventory during checkout.
- Confirm reservations atomically.
- Release holds on timeout or abandonment.
- Reverse on payment failure.
Non-functional
- Strict consistency for inventory state.
- Low latency at the checkout step.
- Resilience to payment provider slowness.
High-level architecture
A transactional reservation database holds inventory per (listing × date range). A short hold reserves capacity during checkout; on payment success, the hold is converted to a confirmed booking. On timeout or cancellation, the hold expires.
Components
Inventory service
Strongly consistent store of capacity and holds.
Hold manager
Issues TTL-bounded reservations; converts on confirmation.
Booking orchestrator
Drives the checkout state machine, integrates payments.
Cleanup worker
Expires unconfirmed holds; releases capacity.
Key decisions
Two-phase: hold then confirm.
Decouples inventory check from payment latency; users see a stable price while paying.
TTL-bounded holds.
Otherwise abandoned checkouts lock inventory indefinitely.
Idempotent confirm step.
Payment provider retries are common; non-idempotent confirms create duplicates or lost bookings.
Strongly consistent inventory.
Eventual consistency is the canonical source of double-booking bugs.
Pitfalls
- Optimistic check without hold — race conditions during simultaneous attempts.
- Indefinite holds.
- Payment retry creating duplicate bookings.
- Splitting inventory across services without a single source of truth.
Follow-up questions
- How do you handle 10,000 simultaneous attempts on the same listing?
- What happens if payment confirms but the booking write fails?
- How do you handle timezone-sensitive availability?