Wooble
Back to GURUSAMI's profile
Verified on Wooble

Queue Cure

Cut 'call next patient' from a 6-step paper flow to 1 tap — both screens sync in <100ms with 0 refreshes, 31/31 real-time tests passing.

V GURUSAMIQueue Cure

6→1

<100ms

91

Overview

76% of India's ~1.5 million clinics still run on paper tokens and memory. Patients wait 2–3 hours with zero visibility. This is a tiny, deployable system that fixes the core loop: issue a token → call the next one → tell everyone where they stand, in real time, with wait estimates based on how fast the doctor is actually moving today. Process A live token-queue system for small clinics, built for Queue Cure '26. Two screens, one source of truth: the moment the receptionist taps Call Next, every waiting-room screen updates instantly — no refresh, no shouting, no paper slips. Receptionist screen — add patients, set average consult time, call the next token. Waiting room screen — big "now serving" board + a personal "how long is my wait?" lookup. Live sync — powered by Socket.IO. Open both screens on any two devices and watch them stay in lockstep. Results Live sync across both screens in <100ms, 0 manual refreshes — verified by automated tests driving two real socket clients. Call next patient: ~6-step paper flow → 1 tap (also N/Space); token numbers auto-assigned, so 0 manual numbering. Wait times computed from the last 10 real consultations, not hardcoded — estimates adapt every consult and self-label as observed vs default. 31/31 end-to-end tests passing, including 2 simultaneous "Call Next" clicks resolved with no skipped or double-served tokens. 12 edge cases handled — no-show removal, one-tap Undo, drain-to-empty, reconnect resync Reflection Persist the queue. State lives in memory, so a server restart clears it. I'd write each mutation to SQLite (or Redis) and rehydrate on boot — the snapshot is already a clean serialization boundary, so it's an additive change, not a rewrite. Make it horizontally scalable. The "event loop serializes everything" guarantee only holds for one process. To run multiple instances behind a load balancer, I'd add the Socket.IO Redis adapter for cross-instance broadcasts and move the authoritative state into Redis with an atomic pop for Call Next. The client contract (state:update) wouldn't change.

Links & files

Artifacts

3

Gallery

4