Manish Kumar

QueueCure AI -Clinic Queue OS

Most neighbourhood clinics still use paper tokens and verbal announcements, leaving patients waiting for hours without knowing their turn. Receptionists manage the entire queue manually, making delays and mistakes common. QueueCure AI replaces this with a simple browser-based system where receptionists manage the queue from one dashboard and patients scan a QR code to see live queue updates and accurate wait times no app installation required. Process I started by extracting the three binary tests from the brief before writing any code: add patient under 10 seconds, live sync without refresh, ETA from real data. Solving those three tests in order determined every architecture decision. For real-time transport I evaluated three options: polling, Server-Sent Events, and WebSockets. Polling adds 1–2 second average latency and wastes bandwidth. SSE is unidirectional — the receptionist can't send events back on the same channel. Socket.IO WebSockets gave bidirectional push under 100ms with built-in reconnection and room-based broadcast — one emit hits every connected screen simultaneously. For state I chose in-memory over a database. A neighbourhood clinic sees 50–100 patients per day. The entire queue fits in under 100KB of RAM. Results All three binary evaluation tests pass: patient token assigned in 3.2 seconds (target under 10), patient screen updates in under 100ms without any page refresh, ETA switches from manual estimate to real rolling average after 3 consultations. Concurrent "Call Next" race condition handled via mutex — tested with two simultaneous socket events, only one executes. Patient screen reconnects after disconnect and receives full current state immediately no stale data. The one-sentence clinic owner moment: watching the patient waiting room screen flip to the new token number on a phone across Reflection I would add browser SpeechSynthesis API for audio token announcements in the first iteration — it requires zero infrastructure, works in any browser, and is critical for clinics with a TV display where patients may not be looking at the screen. I would replace the in-memory mutex with Redis SET NX EX 2 from day one. The boolean flag works for single-node Node.js but breaks silently when you add a second server. Making the architecture horizontally scalable should be a default assumption, not an afterthought. I would also add SQLite as a daily audit log alongside the in-memory queue.