arunabh bhattacharyya

Queue Cure

Traditional walk-in clinics suffer from severe queue mismanagement. They rely on chaotic paper token systems, verbal shouting, or static whiteboards. This leads to three major pain points: (1) High patient anxiety due to unpredictable wait times and fear of missing their turn. (2) Constant interruptions for receptionists ("How much longer?"). (3) A poor, unprofessional first impression of the clinic. The gap identified was the lack of an affordable, highly-visual, real-time synchronization system that can instantly broadcast queue state between the reception and the patient waiting room withou Process I started by architecting a "Single Source of Truth" backend using Node.js and Socket.IO. I initially considered a standard REST API with client-side polling, but quickly discarded it because it lacked the "instant" feel required for a waiting room display and would unnecessarily load the server. By moving to WebSockets, I could instantly broadcast state mutations (token called, patient added) to all connected clients. For the wait time estimation, I realized a simple average was mathematically flawed for clinics; if a doctor suddenly takes 30 minutes on a complex case, the average won't adjust fast enough. I implemented an EMA (Exponential Moving Average) algorithm with an alpha of 0.333 to heavily weight the 3 most recent consultations, resulting in much more accurate predictions. Results Successfully delivered a robust prototype that achieves sub-100ms synchronization between the receptionist dashboard and patient displays. The system successfully handles 11 distinct edge cases (including network drops, empty queues, and accidental skips via a full Undo stack). The EMA algorithm provided significantly more realistic wait time bounds compared to static averages. FRONTEND :https://wooble-hackathon.vercel.app/ BACKEND:https://wooble-hackathon.onrender.com Reflection If I had more time, I would focus on three major architectural and UX improvements: Horizontal Scaling: The current architecture uses a single Node.js instance with an in-memory Socket.IO state machine and SQLite. While lightning-fast for a single clinic, to scale this to a hospital with dozens of departments, I would migrate to a Redis Pub/Sub architecture. This would allow multiple backend instances to share the Socket.IO event stream seamlessly. Patient Independence (Mobile View): Currently, patients must physically sit in the waiting room to watch the TV display. I would implement a QR