Queue Cure '26

Clinics still run on paper tokens: a receptionist calls numbers out loud while a printed board lags behind. Patients can't tell if they're 2nd or 20th, or how long the wait is — so they keep walking up to the desk to ask. With tens of tokens flowing through one consultation room, the hard part isn't data volume. It's keeping the staff desk and the public display in agreement at every moment, showing a wait estimate people can actually trust, and making sure a single mis-click or double-click never skips a patient. Process I started from the failure modes, not the screens. The biggest risk was two displays disagreeing, so I made the server the single source of truth: every change broadcasts one full snapshot, and the screens only render it — they never calculate queue state on their own. I first tried sending small "delta" updates, but that caused ordering bugs and missed events on reconnect, so I dropped the idea. For concurrency I used Node's single thread to my advantage: keeping every state change fully synchronous makes each one atomic with no locks, and a synchronous save keeps memory and disk in step. Only then did I harden the human edge cases — undo, a call-next cooldown, role-gating, input sanitization — and lock the behaviour down with 32 automated tests before spending any tim Results Both screens stay in sync with zero refreshes — every update reaches all connected screens in under a second (~300 ms in my tests), and a dropped client reconnects to the correct state on its own. Calling the next patient is one tap, or a single key press. The server survives a restart without losing the queue or reusing a token number. And the quality is measurable, not assumed: 32 of 32 automated tests pass — covering live sync, persistence, and every edge case — with 0 vulnerabilities in the dependency audit. Reflection Two honest things. First, I built the frontend and backend on mismatched ports and only caught the broken connection when I finally ran them together — I'd write that integration check on day one, not last. Second, I designed for a single consultation room; a clinic with several doctors needs per-room queues, and my call-next cooldown is a sensible heuristic for one room, not a guarantee for many. Next time I'd model multiple rooms from the start and swap the local JSON file for a real datastore with proper auth, so it could safely handle actual patient data.