Wooble
Back to Tanmay's profile
Verified on Wooble1view

Queue Cure '26: Real-Time Clinic Sync

Replaced blind clinic queues with <50ms WebSocket live-sync, featuring adaptive wait-time predictions and 100% idempotent state recovery.

Tanmay SinghQueue Cure '26: Real-Time Clinic Sync

< 50ms

Sync Latency

100%

Idempotent

Zero

API Polling

Overview

Neighborhood clinics rely on paper token slips. Receptionists shout numbers down halls, and patients wait in a blind spot, unable to step outside for fear of missing their turn. The core pain point is wait-time uncertainty: neither the receptionist nor the patient knows how fast the queue is actually moving. Existing solutions are either too complex (requiring patients to download apps) or too rigid, lacking real-time feedback. Process I designed a two-screen architecture (Receptionist Console + Wall-mounted Patient Display) connected via WebSockets. I initially considered computing wait times on the client, but that caused sync issues. I pivoted to a strict server-authoritative state model to guarantee "one truth." For the wait-time algorithm, using a full-day average proved too rigid if the clinic suddenly got busy. I solved this by implementing a rolling average of the last 5 real consultation durations. This made the system instantly adaptive to pace changes. To prevent accidental double-skips by the receptionist, I built a 50-entry UUID idempotency cache on the server that rejects duplicate requests. Results The system achieves <50ms sync latency between the receptionist and the patient display without any manual refresh or database polling. The adaptive wait-time algorithm successfully calibrates itself after just 1 real consultation. By enforcing a UUID cache on the server, we achieved a 100% protection rate against accidental double-clicks. Furthermore, the auto-sync reconnection logic restores full application state instantly if a display temporarily loses Wi-Fi. Reflection I deliberately built this with an in-memory state object to prioritize real-time correctness and speed for the MVP. Next time, I would swap this for a persistent PostgreSQL database to preserve queue state across server restarts. I would also add a multi-doctor dropdown selector directly into the UI. The backend queueStore is already designed to isolate state by doctorId, but the frontend currently defaults to a single global queue to keep the initial UX simple.

Links & files

Artifacts

5

Gallery

4