Skip to content
Booking Engine capability

Capacity and overbooking: hard limits, deliberate exceptions

Updated 4 min read

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?
No. Capacity checks and booking writes happen as one serialised action per session occurrence, so concurrent requests queue for milliseconds rather than racing. The database enforces the final guarantee, not the front end.
Can a session deliberately accept more bookings than its capacity?
Yes, explicitly. Each occurrence carries an overbooked-capacity allowance staff can set to absorb predictable no-shows. Deliberate overbooking is a configured policy; accidental overbooking is prevented architecturally.
Can one date in a recurring series have a different capacity?
Yes. Every occurrence holds its own capacity and counters, so a single date can be adjusted (a smaller studio, a covering instructor) without touching the rest of the series.
See it live

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