Chhavi Bhatt

"Queue Cure — Real-Time Queue & Wait-Time System for Clinics

Local clinics run on paper tokens or a manually-updated whiteboard. Patients can't see their position, so they repeatedly interrupt the receptionist mid-registration to ask "how much longer?" — each interruption costs 30–60s. Wait estimates are guesses that never update as the queue moves. Reception, often a single person handling registration, payments, and calls, becomes the bottleneck if adding a patient takes more than a few seconds. Process I started by observing real waiting-room behavior rather than jumping to a stack, then set 3 testable success criteria: token issued in under 10s, live patient updates with no refresh, and wait time computed from real consult data instead of a guess. That drove the architecture — Express for REST actions, MongoDB as a single evolving document (with an in-memory fallback for demos), and Socket.io split into two event channels: queue:update (broadcast) and patient:subscribe/patient:update (per-token). I considered polling first, but it failed the "call next → instant update" test, which confirmed WebSockets were non-negotiable. I then iterated through concurrency edge cases: simultaneous token issuance, call-next mid-consultation, empty-queue calls, end-of-day resets. Results Receptionist actions (call-next, add-patient) now broadcast instantly to every connected patient screen via Socket.io — no polling, no manual refresh. Wait time shifted from a flat guess to tokensAhead × avgConsultMinutes, with the average updating as a rolling window of the last 20 real consultations. Token issuance was designed and tested to complete in under 10 seconds, and the entire patient flow runs with no login or app install. Reflection I'd add a lightweight load test earlier to validate the Socket.io broadcast under more concurrent connections, rather than just functional testing. I deliberately scoped out SMS notifications, multi-room queues, and patient accounts to ship a focused MVP — the right call for v1 — but SMS is the one I'd revisit first, since not every patient will sit and watch a live screen.