Queue Cure — real-time clinic queue app, synced over Socket.IO

Walk-in clinics relying on a single receptionist have no live link between the front desk and the waiting room. Patients can't see how many people are ahead of them or how long the wait will be, so they keep approaching the desk to ask. Receptionists juggle adding new patients, calling the next token, and adjusting for a consultation that ran long, and can easily lose track of who's actually next. The goal: two screens, receptionist and patient board, perfectly in sync the instant a token is called, with wait times computed from the real queue, not a hardcoded guess. Process I started from the grading weights, not the UI: live sync was weighted highest, so the first call was architecture - the server holds the only copy of state; both screens just render its broadcasts. That decision also solved "wait time from real data" for free, since every estimate recomputes from the live queue on each change. For concurrency, I relied on Node's single-threaded event loop instead of a lock: handlers run to completion with no async gaps, so two "Call Next" clicks can't interleave. An integration test fires a rapid double-click and asserts no token is skipped. What didn't work: granular events (patient added, patient promoted) for screens to diff themselves - dropped once both screens would need to reimplement the server's queue logic, risking drift. Results 11 of 11 integration test assertions pass over real Socket.IO connections: empty-queue handling, invalid-input rejection, wait times recalculating the instant the average consult time changes mid-day, a rapid double "Call Next" applied in order with no token skipped, and removing the currently-served patient correctly clearing "now serving." A 20-trial latency check on localhost showed a median of about 8ms from one screen's action to the other's update. Wait times are never hardcoded - they're recomputed server-side from the live queue on every broadcast. Reflection State is in-memory, so a server restart mid-shift loses the queue; I'd back it with SQLite next, which wouldn't require touching any event handler since they only ever go through four storage functions. I'd also support multiple departments by keying state to a roomId and scoping broadcasts to Socket.IO rooms instead of one global queue. Given more time I'd add a small admin view of the day's served-patient history, which the server already records but never surfaces.