How would you protect the database during a popular ticket sale without trusting Redis for correctness?

Say it in 30 seconds

Say it like this (20-30 seconds)

MiniTickets uses a Redis inventory gate as an advisory fast rejection before the booking transaction. A Lua reservation reduces excess contenders, but Postgres still decides and commits every accepted booking under its row lock. Reservations are settled or reconciled after failures. The gate can undercount and reject valid demand temporarily, so I separate protection from truth. Gate errors fall back to Postgres only for requests that already passed session lookup and rate limiting.

The deeper answer

The gate identifies an intent using the user and idempotency key and gives a reservation an owner token. Missing inventory is initialized from Postgres. A sold-out gate decision still checks for a committed idempotent replay, so a retry can recover a booking that consumed the last seat.

After the database outcome, a newly taken reservation is settled. Failed or replayed work refunds that debit where appropriate. A crash can leave drift, so reconciliation snapshots Redis before reading Postgres and conditionally applies a repair only if the Redis state has not advanced. Live debits are subtracted conservatively, which can temporarily reject demand rather than risk overstating supply.

This reduces hot-row contention but is not a complete waiting room or fairness policy. The current design still does database reads on some rejection paths. A real sale would need explicit admission targets, load tests, customer messaging and a plan for protecting the database when the advisory gate is unavailable.

Counter-questions

Can Redis accidentally let too many requests through?

Yes, through drift, expiry or fallback. They still face the Postgres transaction, which rejects insufficient seats; the consequence can be extra load rather than overselling.

Can Redis reject a customer when seats remain?

Yes. A conservative or stranded debit can temporarily undercount. Reconciliation repairs drift, but the product needs acceptable delay and retry messaging.

Does failing open guarantee bookings during a Redis outage?

No. Session lookup and the shared limiter also use Redis; the limiter fails closed. Only a gate-specific failure after those checks reaches the Postgres fallback.

Where in MiniTickets

Read Rate limits inventory gate, then inspect the inventory-gate piece →.

apps/api/src/services/booking-inventory.ts → createGatedBooking