Slotwise: High-Concurrency Appointment Scheduling
An optimistic appointment reservation architecture that eliminates booking race collisions through distributed 5-minute countdown leases, transparent expiration warnings, and automatic adjacent-slot recovery without discarding patient intake forms.
Live Slot Booking Simulator
Experience high-concurrency booking from the patient's perspective. Select Dr. Vance's 09:30 AM specialist slot, complete the clinical intake form, trigger a simulated timer expiration, and verify that intake data is 100% preserved when swapping to the recommended 10:15 AM alternative.
Slotwise High-Concurrency Booking Journey
Select Appointment
Dr. Sarah Vance, MD · Cardiology1. Operational Scenario: Peak Surge Demand
In clinical practices, specialized medical centers, and premium professional services, appointment release times trigger severe concurrency spikes. When a sought-after cardiology specialist like Dr. Sarah Vance opens her next month's morning availability at 09:00 AM on Monday, hundreds of active patients navigate to the scheduling portal simultaneously.
A patient commuting via train opens the app, identifies an open 09:30 AM appointment, and begins entering their symptoms, primary physician referral details, and insurance copay information. Under naive booking implementations, by the time the patient completes the three-minute form and clicks submit, the slot has already been claimed by another client—resulting in a jarring error modal and the catastrophic deletion of all typed notes.
2. The Concurrency Hurdle: Why Traditional Schedulers Fail
Standard appointment architectures rely on relational database transactions that commit only at the final checkout step. In high-demand scenarios, this causes acute user experience failure modes:
- !The Checkout Collision Trap: The slot appears available throughout the entire checkout journey. The customer expends mental energy filling out intake fields, only to encounter an opaque “Slot no longer available” rejection at payment.
- !Punitive Form Wipes: Naive single-page applications clear their form state when re-routing users back to the calendar view, forcing frustrated patients to re-type complex clinical details or abandon the practice entirely.
- !Double-Booking Race Conditions: In systems lacking distributed locks, two requests arriving within milliseconds of each other can both pass read validation, writing duplicate appointments to the clinician's schedule and necessitating embarrassing manual cancellations.
3. The Architecture: Distributed Leases & Optimistic Holds
Slotwise resolves concurrency collisions by decoupling temporary slot reservation from final booking commit. The application uses a distributed, ephemeral lease pattern backed by Redis keyspaces:
Architectural Workflow
4. Demonstrated UX Decisions in the Interface
Instead of hiding reservation mechanics, Slotwise surfaces a clear emerald badge: “Hold Secured: 09:30 AM (04:58)”. Patients feel reassured that their appointment cannot be snatched while completing paperwork.
When the lease lapses, the app shifts to an informative amber card. Rather than ejecting the patient to a blank calendar, it highlights Dr. Vance's next opening (+45 min shift) with a prominent 1-tap accept button.
5. Interface State Map & Exported Screens
Authentic screen exports captured directly from the Next.js interactive interface state machine:

Real-time slot calendar showing high-demand badges, open times, and concurrency protection rules.

Symptom descriptions and phone verification with persistent background auto-save.

Prominent 5-minute countdown progress bar with fee breakdown and checkout lock.

Alert displaying preserved patient intake and offering a 1-tap swap to the 10:15 AM opening.
6. Edge Case Resilience Matrix
If connectivity drops while the lease is held, the client retains the lease UUID locally. Upon reconnection, it queries Redis: if the lease is still active, the session resumes; if expired, the recovery drawer suggests adjacent times.
Redis single-threaded command evaluation guarantees that exactly one client acquires the lock token; competing clients receive an instant “In Checkout” badge with alternative times.
7. Technical Distinction & Target Architecture
The interactive simulator on this page executes entirely within the browser DOM using a deterministic React state machine. Timer countdowns, expiration triggers, and slot swaps simulate Redis leases without backend round-trips.
Production implementation targets compiled native iOS and Android apps using React Native with TanStack Query and Redis distributed key-expiration listeners (`__keyevent@0__:expired`), providing sub-50ms lease synchronization.
Project Parameters
Observed vs. Target Metrics
Schedule a Consultation
Planning a high-concurrency booking platform or medical scheduling product? We design and build resilient mobile systems with robust data integrity.
Discuss Your Booking App