Developing a Mobile Application for Electronic Queue
A person took a ticket at a service center, went outside, and missed the call — because they didn't hear the announcement. Returned, but their spot was taken by the next number. Mobile app for electronic queue solves exactly this: user doesn't have to sit and watch the board.
Queue Logic and Real-Time Synchronization
Queue isn't just a list. It's state that changes every 2–5 minutes. Client must see current position without manual refresh.
Two synchronization approaches:
WebSocket (preferred): connection stays open while app is active. When next number is called, server broadcasts event to all connected clients in this queue. On Flutter — web_socket_channel, state in Riverpod StreamProvider or BLoC.
SSE (Server-Sent Events): simpler to implement on backend, one-way channel server → client. Works if no two-way communication.
When app goes background — WebSocket closes. Push notifications activate:
- "3 people ahead of you" — reminder, come to office
- "Your number is next!" — time to go to the window
- "You're called to window #5" — immediate notification
Server-side trigger logic: when each number is called, server counts position of each waiting person and sends personalized push to those with 3, 1 position remaining.
Queue Registration
User selects service → system shows current load (average wait time) → confirms entry → gets ticket number and position.
Average wait time — calculated metric: avg(service_duration_last_N) * position. Service calculated from visit history, stored in PostgreSQL, updated by moving average.
QR code of ticket for identification at window without number entry — qr_flutter on Flutter, generated on device from identifier string.
Administrator Cabinet (Operator)
Operator at window sees queue list and calls next person via tablet or PC interface. Call via API → server updates queue → push to client.
Administrator configures: number of active windows, service types, work hours, priority categories (seniors, disabled). These settings affect ticket issuance algorithm.
Pre-Booking and Schedule Integration
Advanced scenario: user books specific time instead of just taking ticket. Then 30 minutes before booking reminder push, 10 minutes — "leave now".
Implementation via server scheduler (Bull Queue): when booking created, tasks put in queue with delayed timing.
Stack and Timeline
Backend: Node.js + PostgreSQL + Redis (for real-time queue state in memory) + Bull (push scheduler).
Mobile: Flutter (iOS + Android) or React Native.
| Scale | Timeline |
|---|---|
| MVP: ticket, position, push | 4–6 weeks |
| + Pre-booking, operator cabinet | 8–10 weeks |
| + Analytics, multi-office, integration | 14–16 weeks |