Case Study / Healthcare
Scheduling that
doesn't buckle
at 9am.
A clinic network in the USA had a booking system that went down during peak hours, roughly weekly. EdgeWeb re-architected it on managed cloud infrastructure with proper concurrency handling — so two front-desk staff can never double-book the same slot, no matter how many requests land at once. See the actual locking logic below.
The Problem & The Approach
The problem
The booking system ran on infrastructure sized for average load, not peak load — and healthcare scheduling is almost never average: Monday mornings and the day after a holiday would reliably knock it over, right when patients and front-desk staff needed it most. Underneath that, the booking logic itself had no real protection against two people booking the same slot at once.
The approach
Two separate fixes, done together: infrastructure that scales for the predictable peaks instead of falling over on them, and a booking flow that acquires an actual lock on a slot before confirming it — so "two patients holding the same appointment" becomes structurally impossible, not just unlikely.
Core System Logic
Five pieces, one reliable calendar.
Distributed Slot Locking
Booking a slot acquires a short atomic lock on that exact appointment before confirming it. If two requests race for the same slot, only one wins — the live demo below runs this exact race.
Cross-Clinic Provider Availability
A provider splitting time across multiple clinics has one real calendar, not a separate one per location that can silently drift out of sync and get double-booked across sites.
Load-Aware Infrastructure
The system scales up ahead of predictable peaks — Monday mornings, the day after a holiday — instead of discovering the limit exactly when patients are trying to book.
Waitlist & Auto-Fill
A cancellation automatically offers the freed slot to the next matching waitlisted patient, instead of it sitting empty until someone notices.
Real-Time Monitoring
Uptime, booking latency and error-rate dashboards alert the team before patients notice a problem, replacing "we found out from a complaint" with an actual early warning.
Try It
Watch the slot-locking logic run.
Book an open slot yourself, or fire three simultaneous booking attempts at the same slot and watch only one actually win it — exactly what stops two patients from holding the same appointment.
Live slot-locking demo
| 9:00 | 9:30 | 10:00 | 10:30 | 11:00 | |
|---|---|---|---|---|---|
| Dr. Patel | |||||
| Dr. Nguyen | |||||
| Dr. Alavi |
Activity log
Architecture
Built to hold up under real concurrent load.
Outcomes
FAQ
How exactly does the system prevent double-booking?
Booking a slot has to acquire a lock on that exact appointment before it's confirmed. If a second request arrives while the lock is held, it's rejected outright and offered the next open slot — it can never silently overwrite the first booking.
Does this integrate with our existing EHR?
Typically yes — the scheduling layer is usually built to sync with the EHR system already in place rather than replace it outright.
What happens during a genuine traffic spike?
Infrastructure scales out automatically ahead of known peak periods, and monitoring alerts the team if load moves outside the expected pattern — before patients experience it as downtime.
How long did a project like this take?
Migrating a network of this size typically runs 10–14 weeks, phased clinic by clinic so no location loses scheduling access during the cutover.
Start a Conversation