QueueX — Real-Time AI Clinic Queue System

76% of India’s 1.5 million clinics still run patient queues on paper token slips and shouted names. Patients routinely wait 2–3 hours with zero visibility into when they’ll actually be seen — they can’t step out for a call, grab food, or plan their day, because the only signal they get is someone yelling a number across a waiting room. Receptionists manage the entire flow from memory: who arrived first, who’s a priority case, who’s already been skipped once. Doctors have no dashboard showing how their day is actually progressing — no sense of average consult time, backlog, or no-show patterns. I reframed this as a distributed-state problem, not a UI problem — the moment two people can act on the same queue simultaneously, race conditions become possible. So I made the server the single source of truth: clients never compute queue order locally. I designed the data model first (Clinic, Token, ConsultLog) so wait time could come from real logged consult durations, not a config value. I built a per-clinic async mutex so concurrent actions queue safely, and an EMA-based predictor with outlier clamping for stable estimates. I added a third screen beyond the brief — a QR patient ticket — since patients feel the "zero visibility" problem most directly. I stress-tested by firing 15 simultaneous requests at the engine, which is what actually caught two real bugs before submission The stress test caught two real bugs before submission: a token-numbering collision during rapid no-shows, and a logic loop where rapid repeated clicking could cycle between the same two patients instead of progressing through the queue. Both were fixed and re-verified — the same test now runs with *zero token collisions across 15 concurrent requests*, correct emergency-priority ordering, and wait times that visibly change after every consultation instead of staying fixed. All three screens — Reception, Waiting Room Display, and Patient Mobile Ticket — update in the same broadcast tick with n With more time, I'd move from the in-memory store to real MongoDB persistence (the schema is already written and ready for this), add authenticated receptionist logins instead of link-based access, and replace the simple no-show frequency counter with an actual ML-based risk score using historical patterns. I'd also want to validate the wait-time predictor against a real clinic's actual patient flow data rather than only simulated test scenarios — the algorithm is sound, but its real-world tuning (the EMA smoothing factor) deserves live data, not assumptions.