QueueDoc — Real-Time Clinic Queue & Token Management System

76% of India's 1.5M clinics still run on paper tokens, leaving patients waiting 2-3 hrs with zero queue visibility. A clinic seeing 40-60 patients/shift faces dozens of "how long now?" interruptions hourly, pulling staff off real queue work. Consultation times vary 2-3x per patient, so flat-average wait estimates are wrong for most of the queue. Existing token systems solve issuance, not the harder problem: syncing two live screens with zero refresh while staying accurate as urgent cases, delays, and no-shows reshape the queue live. QueueDoc solves exactly that. Process Worked backward from 3 constraints — sub-10s check-in, zero-refresh sync, real wait-time math — not features first. Architecture: Node/Express + Socket.io over MongoDB, so state survives a crash. Tokens use an atomic MongoDB counter ($inc) — zero collisions across concurrent check-ins. Wait time: rejected flat (people x avg) math since pace isn't constant. Built an Exponential Moving Average over the last 5 consultations, recalculating within ms of any change. Concurrency: two tabs clicking "Call Next" within ~100ms caused a race condition. Replaced an in-memory flag with a DB-level atomic update (findOneAndUpdate + status check), removing double-advances. Bug found in testing: delay broadcast updated the banner but not wait times — caught by testing against a populated queue. Results Receptionist check-in completes in under 2 seconds per patient — 5x faster than the 10-second target. Both screens update with zero manual refresh, confirmed under repeated concurrent multi-client testing with 0 duplicate or skipped tokens. Wait-time estimates run on a live 5-consultation rolling average rather than a static guess, recalculating within milliseconds when an urgent patient is inserted or a delay is broadcast — verified via the audit trail's timestamped event deltas, showing token-call gaps as low as single-digit seconds during live testing. Reflection My race-condition fix uses a single-instance DB-level atomic lock — correct for one server process, but it wouldn't hold across multiple instances behind a load balancer, since the lock isn't distributed. With more time, I'd move to a Redis-based distributed lock for real production scale across multiple front desks. I'd also convert my manual concurrency tests into automated load tests with more simulated clients, and pilot the receptionist flow with one real non-technical user — every test so far has been run by me as the developer, so I likely can't see friction a first-time user would hit.