Reservation Calendar¶
Scheduling artifact — instantiates Concurrency Control
Turns simultaneous claims on a scarce resource into non-overlapping booked time windows recorded in one shared ledger, so a booking check refuses a clash before it happens.
A Reservation Calendar resolves contention over a scarce resource by moving the fight from real time to scheduled time. Instead of actors racing to grab the resource at the moment they need it, they claim a future window on a shared ledger; the calendar records who holds the resource when, and a new request is accepted only if it does not overlap an existing hold. Its defining move — the one that separates it from a lock or a permit pool — is that allocation is by named resource and time window, booked ahead, and the calendar is the single authoritative record of every claim. Nobody blocks in a live queue; you either get a slot or you are told the slot is taken and pick another.
Example¶
A community makerspace owns one resin 3D printer, and a single print can run six hours. Members book it on a shared wall-and-web calendar in hour blocks. On Friday two members both want Saturday: the first books 9 a.m.–3 p.m., and when the second tries to book 1 p.m.–4 p.m. the calendar's booking check sees the overlap with the existing hold and refuses it, offering 3 p.m.–9 p.m. instead. The second member takes the later window.
Saturday arrives and nobody collides at the machine, because the collision was settled Friday on the ledger. The calendar did not make anyone wait in person and did not count "how many printers are free" — there is only one printer, and the question was never how many but who, and when. Had the makerspace bought three identical printers and stopped caring which one you used, a permit count would have served better; had members needed to grab the printer the instant they walked in, a lock would fit. What the calendar buys is forward coordination of a specific resource whose time is worth planning around.
How it works¶
- Enumerate the reservable resources and their availability. The calendar lists what can be booked — the printer, a conference room, an MRI slot, a consultant's hours — and the windows in which each is free.
- Submit a request for a resource and window. An actor asks for a specific resource over a specific span.
- Check against existing holds. The booking is validated against every current reservation for that resource; any time overlap is a detected clash and the request is refused (or offered a free window).
- Record the confirmed hold. An accepted booking becomes an authoritative entry — resource, holder, start, end — visible to everyone, so later requests see it.
The calendar is a preventive ledger: it stops the double-booking before either party shows up, rather than discovering the conflict when two people arrive at the same machine.
Tuning parameters¶
- Slot granularity — fine slots (15 minutes) versus coarse (half-days). Fine granularity packs the resource tightly and cuts waste; coarse is simpler to administer but leaves gaps stranded.
- Booking horizon — how far ahead claims may be made. A long horizon lets people plan; it also lets early bookers hoard scarce prime windows.
- Changeover buffer — dead time inserted between holds for cleanup, setup, or travel. Buffers prevent back-to-back collisions but lower utilization.
- Hold and cancellation policy — how firm a booking is and what a no-show forfeits. Firmer holds are reliable; looser ones recover wasted slots but invite churn.
- Overbooking factor — whether to book slightly beyond capacity to absorb no-shows. It raises utilization but risks a real collision when everyone shows.
When it helps, and when it misleads¶
Its strength is coordinating a scarce, identity-specific resource ahead of time with a visible, auditable record of who holds what when — ideal for rooms, machines, clinicians, and equipment whose time must be planned around. Nobody waits in a live queue; contention is settled on the ledger.
Its failure modes cluster around the gap between the ledger and reality. No-shows leave booked-but-idle slots that a stricter world would have used, which tempts the classic misuse — overbooking, deliberately selling more claims than capacity (as airlines do) to absorb no-shows, until a day when everyone shows and two real holders collide.[n1] Worse, a booking made outside the calendar — a side deal, a walk-up who "just needs a minute" — silently breaks the whole invariant, because the ledger is only authoritative if every claim goes through it. The guarding discipline is to keep one single source of truth, require check-in and prompt release so ghost holds are reclaimed, and monitor utilization so a bad slot size or a creeping overbooking factor is caught early.
How it implements the components¶
Reservation Calendar fills the map-and-detect pair a scheduling artifact can own:
shared_resource_map— the calendar is the enumerated map of reservable resources and their free/busy windows; it names precisely what can be contested and when it is available.conflict_detection_rule— every incoming booking is checked for time overlap against existing holds, so a double-booking is detected and refused before it happens rather than discovered afterward.
It does not admit an anonymous crowd up to a capacity count — that ordering_or_admission_rule is Semaphore or Permit System's, the nearest twin (a semaphore counts interchangeable slots in use now; a calendar names a specific resource held over a specific window). And it does not reconcile two claims that have already collided — that after-the-fact conflict_resolution_rule is Merge Conflict Review's; the calendar prevents the clash up front instead.
Related¶
- Instantiates: Concurrency Control — the calendar serializes access to a scarce resource by converting simultaneous claims into scheduled ones.
- Sibling mechanisms: Mutex or Lock · Semaphore or Permit System · Collaborative Editing Protocol · Ownership Assignment Matrix · Deadlock Timeout and Detection · Merge Conflict Review · Transaction Isolation · Optimistic Concurrency Check · Facilitated Turn-Taking
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Reservation Calendar operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it turns simultaneous claims on a scarce resource into non-overlapping booked time windows recorded in one shared ledger, so a booking check refuses a clash before it happens.
Independent corroboration: The frozen evidence defines Reservation Calendar as 'Turns simultaneous claims on a scarce resource into non-overlapping booked time windows recorded in one shared ledger, so a booking check refuses a clash before it happens', so its operative form is Control, Automation & Runtime.
Nearest alternative: Record, Log & Register — Reservation Calendar includes features of a persistent ledger, log, register, or case record that preserves history and traceability, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: Shared calendars that allocate exclusive time slots are a longstanding administrative coordination practice.
Related originating lineages:
- Computer Science & Software Engineering — Reservation software operationalized real-time conflict refusal and shared ledgers.
- Operations Research — Scheduling theory formalized non-overlap and capacity constraints.
Review resolution: Both blind reviewers agree that organizational_management is the primary historical origin. Explicit reconciliation of alternate origin disagreement, origin mode disagreement, domain reach disagreement, encyclopedia synthesis disagreement adopts reviewer_a's evidence: Shared calendars that allocate exclusive time slots are a longstanding administrative coordination practice. The selected record uses alternates=computer_science, operations_research, origin_mode=convergent, and domain_reach=universal; the other review proposed alternates=systems_cybernetics, origin_mode=single_lineage, and domain_reach=multi_domain. The selected combination better preserves the mechanism-specific formative lineages and calibrated scope; broader present-day use is not treated as proof of additional historical origin.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Overbooking — the deliberate practice, standard in airlines and hotels, of accepting more reservations than there is capacity, betting that a predictable fraction will not show. It raises utilization but converts a no-show problem into a collision problem on the tail days when the bet fails, which is why an overbooking factor is a risk dial, not a free lunch. ↩