Palak Agarwal

Real-time Clinic Queue Management System

Walk into any small clinic in India and you'll see the same broken system — a receptionist shouting token numbers, patients crowding the door, and nobody in the waiting room knowing if they have 5 minutes or 45 minutes left. The real problem: the receptionist and the waiting room have zero shared information in real time. One person has all the context, 20 people are guessing. Patients either hover near the counter blocking others, or step outside and miss their turn. The receptionist gets interrupted constantly with "how long?" questions. I built CureQ to fix this with zero hardware and ze Process I started by mapping two completely different users — the receptionist who controls the queue, and the patient who just wants to know when their turn is coming. Both need the same data but displayed completely differently. I built polling first — fetching queue state every second. It worked but felt laggy. A 5-second delay on a waiting room display is unacceptable. I switched to Socket.IO so updates fire the instant "Call Next" is clicked. The hardest part was concurrency. Two receptionists clicking simultaneously would both read the same next patient and call them twice. I solved this with a MongoDB atomic distributed lock — only one operation can win at a time. The second waiter polls every 25ms for up to 5 seconds. I also handled server crash recovery — if the server crashes mid-oper Results Both screens — receptionist desk and patient waiting room display — update in under 100ms when "Call Next" is clicked. No refresh, no delay. Wait time shown to patients is computed from real queue position and the clinic's actual average consultation time — not a guess. The system handles the edge cases that break most beginner projects: simultaneous clicks are blocked by a MongoDB lock, server crashes auto-recover on restart, network drops trigger a polling fallback so the display never freezes. Deployed live on Render with MongoDB Atlas. Full-stack system working end to end with zero manu Reflection I'd test the MongoDB connection in isolation before wiring up the whole server. I spent significant time debugging a DNS issue with Atlas that a 5-line test script would have caught immediately. I'd also add SMS notifications via Twilio. Right now patients must watch the screen — if someone steps outside they miss their turn. A text saying "You're next, please return" would make this genuinely production-ready. I'd deploy from day one instead of running locally. A live URL forces you to handle environment configuration properly early and makes demos much stronger. Finally, I'd add a simple