SysPad › Examples › Hotel reservation system
Hotel reservation system
A cache-backed Search Service (staleness-tolerant) is split from a Reservation Service that writes straight to the primary DB (strong consistency, to avoid overbooking), then queues an async confirmation email.
Deliberately different consistency requirements on two paths sharing the same inventory database.
- Throughput: 4,000 req/sec
- First to saturate: Payments
- Estimated cost: $530k/mo
How it works
- Search Service
- Reads are cache-first and tolerate slight staleness: a room that shows available but was just taken is caught at booking time, so serving a 30-second-old availability list is an acceptable trade for speed.
- Inventory Cache
- Absorbs the search read storm - 90% of availability lookups never reach the DB. The 10% miss reads through from the service, not from the cache, so the miss load lands on the DB as a normal query.
- Reservation Service
- Writes go straight to the primary DB, never the cache: a booking must be strongly consistent or two guests get the same room. This is the deliberate opposite trade to the search path.
- Inventory DB
- The shared node both paths meet on: search reads it (cache misses) while booking writes it (every reservation). One store, two consistency contracts - strong consistency where it matters.
- Confirmation Queue
- Decouples the confirmation email from the booking response: the reservation is committed and returned the moment the row is written, and the email is sent whenever the handler drains this queue.
Request flows
Search availability
- Client
- Load Balancer
- Search Service
- Inventory Cache
- Inventory DB
Book a room
- Client
- Load Balancer
- Reservation Service
- Inventory DB
- Payments
- Confirmation Queue
- Confirmation Handler
- Confirmation Email