Appointments Architecture & Specs
An enterprise scheduling engine built with distributed locking, deterministic availability calculation, and cross-module synchronization — so double-bookings simply can't happen.
Performance Metrics
Concurrency Safety
Zero double-bookings, even when multiple customers try to claim the same slot at the same instant
Reminder Delivery
Automated reminders go out within minutes of when they're due
Calendar Sync
Respects Google's and Microsoft's API limits automatically — no manual throttling or babysitting required
High-Volume Ready
Built to handle high booking volumes per resource without slowdown
1. The Availability Engine
Availability is calculated in real time on every request — never cached — so a slot you see as open is always genuinely bookable. - How it works: The engine reads the appointment type's constraints (duration, buffers, minimum notice), resolves the resources a booking requires, determines working windows for the requested date (respecting any date-specific overrides), generates candidate slots, and filters out anything that conflicts with an existing, non-cancelled booking. - Conflict Detection: A slot counts as taken when its buffered window overlaps any existing booking's buffered window — so buffer time between appointments is always honored, not just the raw appointment length.
2. Concurrency & Distributed Locking
Real-time availability tells a customer a slot is open, but the dangerous moment is the split second when two people try to claim the same open slot at once. That's where the distributed lock comes in. - Serialized slot claims: When a booking is created, the engine acquires a short-lived distributed lock keyed to the specific resource and time slot before it writes anything. Two simultaneous requests for the same slot are serialized — one acquires the lock, the other waits — so the race never resolves into a double-booking. - Re-check inside the lock: Availability is confirmed a second time after the lock is held, not just when the slot was first displayed. If the slot was taken in the milliseconds between page load and submit, the second request is rejected cleanly with a conflict rather than silently overwriting the first. - Release on completion: The lock is held only for the duration of the write and released immediately, so throughput per resource stays high — the lock protects correctness without becoming a bottleneck under real booking load.
Frequently Asked Questions
No. Booking creation acquires a distributed lock keyed to that resource and slot, re-checks for conflicts inside the lock, and only then writes. Simultaneous requests are serialized — one wins, the other gets a clean conflict response.
Never. Available slots are computed in real time on every request from the appointment type's constraints, the resource's working windows, date-specific overrides, and existing non-cancelled bookings — so a slot shown as open is always genuinely bookable.
Conflicts are evaluated on the *buffered* window, not the raw appointment length. A slot is taken when its buffered window overlaps any existing booking's buffered window, so the gap you configure between appointments is always preserved.
They follow the RFC 5545 recurrence standard used by Google Calendar and Outlook. The series is generated automatically several months ahead, and a single occurrence can be rescheduled or cancelled as a one-off exception without disturbing the rest of the series.
A sync failure never blocks a customer from completing a booking. Bookings still commit locally and reconcile to the external calendar afterward, and the sync layer respects Google's and Microsoft's API rate limits automatically so you never have to throttle it by hand.