Bhanu Sanikommu

QueueCare — Real-Time Clinic Queue Management with Atomic Token Locking

Indian clinics still use paper chit tokens. Patients arrive, get a slip, and sit for hours with zero visibility — no ETA, no position updates, no idea when to return. Receptionists manually shout token numbers, causing missed calls and chaos. Worst of all, when two receptionists manage the same queue, they can accidentally call the same patient — the "double-token" race condition. We identified 3 core pains: (1) patient anxiety from zero wait visibility, (2) receptionist overload from manual queue ops, and (3) data concurrency bugs in existing digital queue tools. [24/06, 2:33 pm] anu: Indian clinics still use paper chit tokens. Patients arrive, get a slip, and sit for hours with zero visibility — no ETA, no position updates, no idea when to return. Receptionists manually shout token numbers, causing missed calls and chaos. Worst of all, when two receptionists manage the same queue, they can accidentally call the same patient — the "double-token" race condition. We identified 3 core pains: (1) patient anxiety from zero wait visibility, (2) receptionist overload from manual queue ops, and (3) data concurrency bugs in existing digital queue tools. [24/06, 2:33 pm] anu: We started by visiting 3 local clinics in Bangalore and observed the full patient journey — from walking in to walking out. We mapped the pain points into a Mermaid sequence diagram and Built a production-ready system with: (1) Zero race conditions — PostgreSQL atomic locking guarantees no two receptionists can call the same token, even at the exact same millisecond. (2) Real-time sync — Socket.io broadcasts update all screens in <200ms. (3) Patient self-service — QR scan → join queue → live tracking with voice announcements. (4) Resilient state — Zustand persists tokens to localStorage so patients don't lose their spot on tab close. (5) Dynamic ETAs — receptionists adjust avg consultation time mid-day, instantly updating all patient screens. Three things: (1) I'd add automated load testing using k6 or Artillery to stress-test the FOR UPDATE SKIP LOCKED query under 500+ concurrent "Call Next" requests — we proved correctness logically but didn't benchmark at scale. (2) I'd implement a Redis pub/sub layer instead of in-memory Socket.io for horizontal scaling across multiple serverless instances. (3) I'd add an SMS fallback for patients without smartphones using Twilio, since not all clinic patients in India have reliable internet. These are honest gaps I'd close in a v2.