Capacity and overbooking: hard limits, deliberate exceptions
Every session occurrence in the Booking Engine carries its own capacity, live booked and waiting counters, and an explicit overbooking allowance. Capacity checks and booking writes are one serialised action, so the last place can never be sold twice, and any deliberate exception to a limit is configuration, not an accident.
What does the capacity model do?
It makes “how full is this session?” a question with exactly one answer, and makes every exception to a limit deliberate.
- Per-occurrence limits. Capacity lives on each scheduled occurrence, not just the parent session, so one date can differ from the rest of its series.
- Live counters. Booked, waiting, and attended counts are maintained on the occurrence and updated in the same transactions that change them. Dashboards read them directly; nothing is recounted or synced.
- Sub-capacities. Separate limits for trial places and make-up places let operators ring-fence capacity for prospects and catch-ups without eating regular places.
- An explicit overbooking allowance. Where no-shows are predictable, staff can set an overbooked capacity per occurrence. The system distinguishes policy (a configured allowance) from defect (a race), and prevents the second architecturally.
- Serialised checks. The capacity check and the write that consumes a place happen under a per-occurrence lock, the design detailed in checkout reservations. Demand beyond the limit flows into the waitlist atomically.
Why per-occurrence capacity matters
Real schedules are not uniform. A weekly class moves to a smaller room for one date; a workshop runs a double session before a holiday; a trial day needs five ring-fenced places. Systems that model capacity only at the class level force workarounds for all of these, and workarounds are where double-bookings live. Modelling capacity per occurrence, with its own counters and its own overrides, makes the exceptions ordinary configuration.
Why it matters commercially
Capacity is revenue with a ceiling. Undersell it and places go empty; oversell it and refunds and apologies follow. A model with hard per-occurrence limits, live counters, ring-fenced sub-capacities, and deliberate overbooking allowances lets operators run sessions at their true limit with confidence. The companion guide below covers the contention engineering that keeps those limits honest under high demand.
Frequently asked questions
Can two staff members double-book the last place in a session?
Can a session deliberately accept more bookings than its capacity?
Can one date in a recurring series have a different capacity?
More Booking Engine capabilities
Waitlists: positioned queues that never race
How the Booking Engine handles full sessions: atomic waitlist joins with explicit queue positions, configurable queue sizes, and live waiting counts.
Checkout reservations: hold a place while the customer pays
How the Booking Engine holds places during checkout: time-boxed reservations with configurable expiry, lazy release, and guarded atomic confirmation.
Term scheduling: terms, site variations, and skip dates
How the Booking Engine schedules term-based programmes: named terms, per-site term variations, skip dates for closures, and occurrences generated per date.
See this working in a demo
Book a consultation and we will demonstrate this capability on the Booking Engine accelerator, against your own scenarios.
Book a demo