Why "Check Then Write" Booking Logic Breaks Under Real Traffic (And How to Fix It in PostgreSQL)

Qasim Lak — Tue, 22 Sep 2026 18:06:34 +0000

Most booking and reservation systems check-availability-then-write as two separate steps. It looks fine in every demo. It breaks the first time two people click "Confirm" within the same second — which, if your product has any real usage, happens constantly during peak times.

I ran into this building a booking engine for Pakistani wedding venues, where the cost of a bug isn't a support ticket — it's two families showing up for the same hall on the same night.

The race condition, concretely
Time 0ms: Request A checks hall availability → sees "free"
Time 5ms: Request B checks hall availability → sees "free"
Time 10ms: Request A writes booking → succeeds
Time 12ms: Request B writes booking → also succeeds

Both bookings look valid. Nothing crashed. You just sold the same slot twice.

Why this still catches people in 2026

Modern stacks (Next.js Server Actions, edge functions, serverless) make it easier to accidentally spread a "check" and a "write" across different requests or even different regions, which makes this race condition more likely, not less, compared to a single monolithic server handling one request at a time.

The fix: push the guarantee into the database, not the app

Application-level checks (if (available) { book() }) can't prevent this — by definition, two parallel requests both pass the check before either writes. The fix has to live where writes are serialized:

Row-level locking (SELECT ... FOR UPDATE) so the second transaction waits for the first to finish before it even reads.
A unique constraint on (hall_id, date, timeslot) as your last line of defense — even if your locking logic has a bug, the database itself refuses the duplicate.
Idempotency keys on the write endpoint, so a retried request (flaky network, double-click) can't create a duplicate on its own.

This is the same category of problem seat-selection systems and ticketing platforms solve, just at smaller scale.

I'm Qasim Lak, a software engineer and web developer in Islamabad, currently building production-style systems around booking concurrency, network telemetry, and offline-first mobile sync. More at qasimlak.me.

DEV Community: Qasim Lak

Why "Check Then Write" Booking Logic Breaks Under Real Traffic (And How to Fix It in PostgreSQL)