Waitlists: positioned queues that never race

What does the waitlist capability do?

A full session stops being a dead end. Members who want a place are queued in order, staff see the demand live, and the operator keeps a ranked list of customers who tried to pay rather than an empty analytics gap.

• Atomic joins. The waitlist offer happens inside the same serialised transaction that discovered the session was full. There is no gap between “booking failed” and “queue joined” for a race to hide in.
• Explicit positions. Every entry records its queue position, assigned as the next position in sequence under the same lock that guards bookings. Members get a definite answer: a held place, or position N.
• Bounded queues. The maximum queue size is configurable per service, and waitlisting itself is a per-session toggle. Queues stay honest instead of growing into mailing lists.
• Live counts. Each session occurrence maintains a waiting count next to its booked count, so admin views and reports read demand directly rather than recounting.
• No duplicates. A member cannot hold two entries for the same occurrence; repeat requests return the existing entry.

How is it modelled?

Waitlisted is a status in the same booking record lifecycle as confirmed, cancelled, no-show, and checked-in. That single design decision means waitlist entries inherit everything bookings have: the audit trail, the admin views, duplicate prevention, and API access. Staff manage the queue through the same API that manages bookings, so promoting a waitlisted member into a freed place is a status transition, not a copy between systems.

The queue mechanics sit on the platform’s serialised reserve flow, described in checkout reservations and capacity and overbooking. One request, one definite outcome: reserved, or waitlisted with a position.

Why it matters

Waitlist data is the strongest demand signal an operator has. Consistently long queues on particular days, sites, or sessions are a direct instruction about where to add occurrences or capacity, and the live waiting counts make that signal reportable rather than anecdotal. For the full design thinking, including the promotion models and what to demand in any vendor demo, see the companion guide linked below.