Queue Cure — Real-Time Clinic Queue System

76% of India's 1.5 million clinics still run on paper token slips and manual shouting. Patients wait 2-3 hours with zero visibility into their queue position, doctors have no real-time dashboard, and receptionists track everything from memory. There's no shared source of truth between the front desk and waiting patients — leading to confusion, repeated questions, and wasted time for everyone. I set out to build a lightweight, real-time system that gives both sides instant, synced visibility into the queue without adding any operational overhead. Process I started by identifying the single most important requirement: both screens must update instantly without refresh, since that's what actually solves the visibility problem. This led me to a server-centric architecture — one in-memory queue on the backend, with Socket.io broadcasting every change to all connected clients. I built the backend first (Express + Socket.io), testing queue logic with simple events before touching any UI. Then I built the Receptionist screen, followed by the Patient screen, reusing the same socket connection so both stay perfectly in sync. Once the core flow worked, I added validation (empty names, empty queue) and a debounce lock to prevent race conditions from rapid double-clicks on "Call Next" — since that's the kind of real-world edge case a live clinic would Results Delivered a fully working real-time queue system where both the Receptionist Dashboard and Patient Waiting Room update instantly via WebSocket broadcasts — zero manual refresh required. Wait time is computed live from actual queue length and receptionist-set average consultation time, not hardcoded. Tested edge cases including empty patient names, empty queue calls, and rapid double-clicks on "Call Next," all handled gracefully with validation and a debounce lock. The result: a lightweight MVP that could realistically replace paper tokens in a small clinic with zero training overhead. Reflection With more time, I'd persist queue state to a real database instead of in-memory storage, so a server restart doesn't wipe the queue. I'd also add receptionist authentication, since right now anyone with the URL can act as the receptionist. For multi-counter clinics, I'd extend the system to support multiple doctors/counters running independent queues simultaneously. Finally, I'd replace the single global average consultation time with per-patient estimates based on visit type, for more accurate wait predictions on the patient screen.