Queue Cure - Real Time Clinic Queue System That Kills the 2-Hour Wait

76% of India's 1.5 million clinics still run on paper token slips and shouting. Patients wait 2–3 hours with zero visibility - they can't leave, can't track progress, and often miss their token when called. Receptionists manage everything from memory: no dashboard, no queue order, no estimated times. The gap isn't technology - basic smartphones and WiFi exist in most urban clinics. The gap is a tool simple enough for a receptionist to learn in 30 seconds and useful enough for a waiting patient to trust. That's what I set out to build. I started with the constraints: the receptionist has 5 seconds per action - no complex UI. The patient checks their phone once and expects a number that's actually right. For live sync, I chose Socket.io rooms over polling. Polling creates stale windows; WebSockets push changes in <20ms. I mapped two roles to two rooms: receptionist gets full state, patient gets sanitized state - no internal IDs exposed. The hardest design decision was ETA. Hardcoding "5 minutes × position" is wrong - doctor speed varies. I built a rolling average over the last 10 actual call intervals, blended with the receptionist's configured time by confidence (low → medium → high). For concurrency, I relied on Node.js's single-threaded event loop — two simultaneous "Call Next" clicks cannot both advance the queue. All four evaluation criteria verified through automated socket integration tests: live sync confirmed across simultaneous receptionist + patient clients; ETA computed from real rolling averages (not hardcoded) with data confidence indicator; receptionist actions validated for edge-case rejection (empty name, out-of-range time, empty queue call, simultaneous double-advance blocked). The UI renders in <1.3s (Vite build), socket events resolve in <20ms on localhost. ETA accuracy improves automatically as the clinic day progresses - no reconfiguration needed. QR code lets patients self-check witho I add SMS/WhatsApp alerts (via Twilio) so patients can leave the clinic when they are 3 tokens away - the biggest real-world pain point I didn't solve. I also persist state to Redis so a server restart mid-day doesn't wipe the queue - in-memory was the right MVP call but a clinic can't afford that failure. Finally, I'd do one round of real receptionist testing before finalising the UI - I assumed keyboard-first is fastest, but a receptionist used to touchscreen phones might disagree. Self-awareness: I over-engineered the ETA blending. A simpler "use real data after 5 calls" would have been