I fired 20 simultaneous bookings at a typical booking app. All 20 got the slot.

Andy Scott — Fri, 23 Oct 2026 08:44:35 +0000

The app you built in an afternoon

Ask Claude Code, Cursor or Lovable for a booking app for a barbershop and you'll have one by teatime. Services, staff, a calendar, Stripe checkout. It looks done, and every test you write for it passes.

Then on a Saturday morning two customers pick 10:00 with the same barber, a second apart. Both get a confirmation email. One of them turns up to find someone already in the chair.

This isn't a bad model or a lazy prompt. It's the same bug in almost every booking app that gets generated or written quickly, and tests that send one request at a time can't see it. Here's what it looks like, a test that catches it, and what fixing it properly involves.

The check every generated scheduler writes

Under the calendar there's nearly always an appointments table and a check for overlaps before each insert. With Prisma it looks like this:

async function book(staffId, start, end) {
  const clash = await prisma.appointment.findFirst({
    where: { staffId, start: { lt: end }, end: { gt: start } },
  })
  if (clash) throw new Error('Slot taken')
  return prisma.appointment.create({ data: { staffId, start, end } })
}

The overlap condition is right: two ranges overlap when each starts before the other ends. Reviewers nod it through. The problem isn't the condition, it's that checking and inserting are two separate steps.

Two customers, one slot

When two requests arrive close together, both run findFirst before either runs create. Both see an empty slot, so both insert.

Customer A                       Customer B
findFirst: no clash
                                 findFirst: no clash
create: booked
                                 create: booked   <- two bookings, one chair

It doesn't take much traffic. A popular barber on a Saturday, a class that just opened, or one customer double-tapping the button on a slow phone will do it.

The fix has to make the database refuse the second booking, not the application. In Postgres the cleanest way is an exclusion constraint, which rejects any row whose time range overlaps another for the same staff member:

CREATE EXTENSION IF NOT EXISTS btree_gist;

ALTER TABLE appointment
  ADD CONSTRAINT appointment_no_overlap
  EXCLUDE USING gist (
    staff_id WITH =,
    tstzrange(start_at, end_at) WITH &&
  );

Now the second insert fails with error 23P01 (exclusion violation), however close together the requests are. Catch it and tell the customer the slot has just gone.

One catch if you use Prisma: its default DateTime column is timestamp without a time zone, and Postgres refuses tstzrange on it ("functions in index expression must be marked IMMUTABLE"). Declare the columns @db.Timestamptz(3), which is what appointment times should be anyway, or use tsrange.

The constraint only covers one table and one rule. Once a booking needs a staff member and a room, or bookings can be cancelled and should free their time, you need to filter the constraint on status and lock rows in a consistent order inside a transaction, or two bookings for two resources start deadlocking each other.

The customer who is still paying

Between picking a time and finishing checkout, a customer might take two minutes or twenty. Generated apps usually do one of two things here, and both go wrong.

Book after payment. Someone else books the slot while the first customer is typing their card number. They pay for a time they no longer have.
Book before payment. The slot is taken for good, even when the customer closes the tab. Abandoned checkouts quietly fill the diary.

What works is a hold: a booking marked pending, with an expiry time, that counts as taken until it either lapses or is confirmed. That brings three rules with it.

Availability treats an unexpired hold as taken and an expired one as free, at the moment you ask, without waiting for a cleanup job.
Confirming re-checks the expiry under the same lock as booking. A payment that lands a second after the hold lapsed must not confirm a slot someone else now has.
Something releases lapsed holds and tells the rest of your app, so a waiting customer can be offered the time.

Clock changes

A recurring booking is where this shows first. "Every Tuesday at 9:00" sounds like one time, but it's two different UTC times either side of the clocks changing. The usual generated code adds a week in milliseconds:

const WEEK = 7 * 24 * 60 * 60 * 1000
const first = new Date('2026-10-20T09:00:00+01:00') // 9:00 in London, summer time
const next = new Date(first.getTime() + WEEK)
// 2026-10-27T08:00:00.000Z: 8:00 in London. The clocks went back on the 25th.

The customer's standing appointment has moved an hour and nobody touched it. The fix is to store the rule in local time with its timezone ("Tuesdays, 09:00, Europe/London") and work out each date's UTC time from that, not from the one before.

The edges matter too. When the clocks go back, 01:30 happens twice; when they go forward, 01:30 doesn't happen at all. A shop with a site in Madrid and one in London needs each site's hours in its own zone. None of this turns up in tests unless a test runs across a clock change.

Buffers and services that need two things

The overlap check assumes one booking uses one person for its whole length. Real services don't.

Buffers. A 45-minute cut with 10 minutes of cleanup blocks the chair for 55, but the customer should still see 45. The overlap check has to use the padded time while the confirmation shows the real one.
Two resources. A massage needs a therapist and a room. Both have to be free, and both have to be taken in one step, or a second booking grabs the room between the two inserts.
Gaps in the middle. A colour needs the stylist for 30 minutes, then not for 30 while it develops, then again. The stylist is free to take someone else in the gap.
"Anyone available". Picking the first free barber is another check-then-insert. Two customers asking for anyone can both be given Sam.

Each of these is fixable. Together they turn a table and a check into a scheduling engine.

A test that catches it

The fix starts with a test that fails. Fire 20 bookings for the same slot at once and count how many succeed. The answer should be one.

import { test } from 'node:test'
import assert from 'node:assert/strict'
import { book } from './booking.js'

test('one of 20 simultaneous bookings for a slot succeeds', async () => {
  const start = new Date('2026-11-14T10:00:00Z')
  const end = new Date('2026-11-14T10:45:00Z')

  const results = await Promise.allSettled(
    Array.from({ length: 20 }, () => book('staff_1', start, end)),
  )

  const booked = results.filter((r) => r.status === 'fulfilled').length
  assert.equal(booked, 1)
})

Here's what it did with the Prisma code above, 20 runs of 20 bookings each:

Setup	Bookings that succeeded, per run of 20	Runs that double-booked
Check-then-insert, Postgres, pool of 20 connections	20 (1 on the first run)	19 of 20
Check-then-insert, Postgres, pool of 1 connection	20	20 of 20
Check-then-insert, SQLite	19 or 20	20 of 20
With the exclusion constraint	1	0 of 20

Two things surprised me. The first run passed, because the pool was still opening connections one at a time, which spaced the requests out. So run it more than once.

And neither a single connection nor SQLite saves you. All 20 reads run before any of the 20 writes, however the queries queue, so every one of them sees an empty slot.

Add a second test that holds a slot, moves time past its expiry, and checks that the confirm is refused. Then one that books a weekly series across the last Sunday in October and checks every date stays at 9:00 local.

Build it, or hand it off

You don't always need any of this. A table and a check are fine when:

one person takes bookings for themselves and can sort out the odd clash by phone,
there's no payment between picking a time and booking it, and
everything happens in one timezone, with no recurring bookings, buffers or shared rooms.

If you're building for many businesses, each with staff, rooms and customers paying online, the scheduling is a product of its own. You can build it: an exclusion constraint, holds with expiry, rules in local time, locks taken in a fixed order, and tests for each. Or you can hand it to a service built for it.

That's why we built Tiempo, a scheduling API for booking platforms. Your app keeps its services, prices, customers and payments; Tiempo keeps the time. Every booking locks the resources it touches, so the race above ends in one booking and one 409. Holds expire on their own, recurring bookings keep their local time through clock changes, and buffers, two-resource services and "anyone available" are built in. It has a free test mode, and a rules file you can give your coding agent so it uses Tiempo instead of writing a scheduler.

To see all of it in one place, the booking starter is a small Next.js barbershop app on Tiempo: pick a service, a barber or anyone, and a time, and the slot is held while you pay, with Stripe or a built-in test page. A payment that lands after its hold ran out is refunded, not forced through. It ships with the race test from above, aimed at the real thing:

20 customers racing for 2026-10-23T08:15:00Z...
Held: 1. Refused with 409: 19. Other errors: 0.
Pass: one booking, no double-booking.

It's MIT-licensed, and its AGENTS.md tells your coding agent how it uses Tiempo, so you can fork it and ask the agent to turn it into your product.

Whichever way you go, write the race test first. It's ten lines, and it tells you whether your booking app can be trusted on a busy Saturday.

DEV Community: Andy Scott