Skip to main content
Selected Work/Slotwise
Concept study · Interactive prototypeHealthcare & Wellness · Resource Booking

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.

Study ClassificationInteractive Concept Study
Current Delivery StageInteractive Web Prototype
Simulated Prototype TechNext.js / TypeScript
Proposed Production RuntimeReact Native / Redis Leases
Demonstration Environment

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.

Interactive Prototype SimulatorNext.js / TypeScript Local State Machine

Slotwise High-Concurrency Booking Journey

Journey Guide:
1. Calendar→2. Patient Intake→3. Slot Hold→4. Expiration Alert→5. Confirmed
09:41
5G CELLULAR92%

Select Appointment

Dr. Sarah Vance, MD · Cardiology
Specialist
Mon
24 Sep
Tue
25 Sep
Wed
26 Sep
Thu
27 Sep
Available Morning Slots:
5-Minute Concurrency Guarantee
Selecting a slot places a distributed hold lease in Redis, preventing race collisions while you enter intake notes.
Schedule Elena R. Encrypted

1. 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

1. Ephemeral Distributed Lock (SET NX PX):When a user taps an open slot, the server executes an atomic Redis `SET slot:vance:0930 user:elena NX PX 300000` command. If successful, the slot is locked exclusively for 300 seconds (5 minutes), immediately broadcasting a “Held” state across WebSocket subscriptions to all other concurrent clients.
2. Reactive Client-Side Countdown Timer:The mobile client displays a prominent 5:00 countdown timer. A background heartbeat keeps the lease alive while the user actively types in intake fields, ensuring uninterrupted form entry.
3. Local Intake Persistence & Graceful Fallback:Patient intake fields auto-save to local memory with every keystroke. If the 5-minute timer expires, the slot is cleanly released back to the general pool, but the user is immediately presented with adjacent available options (e.g. 10:15 AM) that inherit all pre-filled intake data in a single tap.

4. Demonstrated UX Decisions in the Interface

Transparent Concurrency Guarantees

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.

Non-Destructive Expiration Recovery

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:

Slotwise Screen 01 - Provider Availability Grid
Screen 01 · Availability Grid

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

Slotwise Screen 02 - Patient Clinical Intake
Screen 02 · Clinical Intake Form

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

Slotwise Screen 03 - Active Slot Hold Timer
Screen 03 · Active Hold Countdown

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

Slotwise Screen 04 - Expiration Alert & Recommended Slot
Screen 04 · Expiration Recovery

Alert displaying preserved patient intake and offering a 1-tap swap to the 10:15 AM opening.

6. Edge Case Resilience Matrix

Edge State: Cellular Disconnect During Checkout

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.

Edge State: Simultaneous Multi-Client Claim

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

Simulated Prototype RuntimeNext.js / TypeScript

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.

Proposed Production RuntimeReact Native / Expo + Redis Leases

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

Client / DomainHealthcare Specialist Scheduling
Primary User PersonaElena, Commuting Specialist Patient
Critical UX Feature5-Minute Ephemeral Lease + Auto-Recovery

Observed vs. Target Metrics

Prototype Booking Cycle
35s
Average time to hold and complete booking in simulation
Intake Preservation Rate
100%
Zero typed characters lost upon timer expiration swap
Target Collision Rate (Production)
0.00%
Redis distributed lease zero-tolerance concurrency threshold

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