The problem of the electronic queue and its solution
Note: when at an MFC or another institution with a large flow of clients, a traditional queue is stress. People take a ticket, go outside, and miss their call. Upon returning, they discover that their number has already been canceled, and they have to wait for a repeat issuance.
Operators spend time on reassignment, and overall throughput drops. A mobile application for an electronic queue solves this problem: tickets are synchronized in real time via WebSocket, and personalized push notifications warn 3, 2, and 1 position before the call.
According to our projects' data, downtime is reduced by 40%, and personnel costs are reduced by up to 20% through automation. Developing a mobile application for an electronic queue is an investment that pays off through reduced costs and increased customer loyalty.
How the Mobile App for an Electronic Queue Works
A queue is not just a list. The state changes every 2–5 minutes, and the client must see the current position without manually refreshing. We use WebSocket for instant synchronization — the latency does not exceed 100 ms. This architecture handles a load of up to 5000 simultaneous connections.
Two approaches to synchronization:
- WebSocket (preferred): the connection stays open while the app is active. When the next number is called, the server broadcasts an event to all connected clients. On Flutter —
web_socket_channel, state inRiverpod StreamProviderorBLoC. Latency — no more than 100 ms, which is 3 times faster than SSE. - SSE (Server-Sent Events): simpler to implement on the backend, a unidirectional channel. Latency ~300 ms.
Note: when the app goes to the background, the WebSocket closes. Then push notifications kick in:
- "3 people left ahead of you" — a warning.
- "Your number is next!" — time to come up.
- "You are being called to window No. 5" — an immediate notification.
Server logic: on each call, the position of every waiting person is calculated and personalized notifications are sent to those who have 3, 2, 1 position left.
More about setting up push notifications
For iOS, APNs is used; for Android, FCM. Correct configuration of certificates in App Store Connect and keys in Firebase Console is required. Push notifications go through App Store Review Guidelines Section 5.1. For additional protection, code signing and a provisioning profile are used.
How does pre-booking work?
An advanced scenario: the user doesn't just take a ticket but books a specific time.
30 minutes before the slot, a reminder push arrives; 10 minutes before — "leave now." Implementation via Bull Queue on Redis: when a booking is created, tasks are placed in the queue with delayed timing. This reduces the number of no-shows by 35%.
Why should you choose Flutter for an electronic queue?
Flutter allows you to cover iOS and Android with a single codebase, which cuts development cost by 1.5 times compared to native apps. Building via fastlane and delivering updates via Code Push (Shorebird) make it possible to fix bugs without App Store approval. Animations and UI run at 60 FPS even on older devices.
Work Process: From Idea to Deployment
- Analytics: we study the load, number of windows, types of services, user scenarios.
- Design: queue architecture (in-memory Redis queue), API schemas, mockups.
- Implementation: backend on Node.js + PostgreSQL, mobile on Flutter, push setup (FCM/APNs).
- Testing: load testing (up to 1000 concurrent users), usability.
- Deployment: CI/CD setup, uploading to app stores, connecting monitoring (Crashlytics).
Contact us to discuss your project and get a preliminary estimate.
What is included in mobile app development?
- Mobile app development (iOS + Android) and backend service
- Integration with existing systems (e.g., MFC ACS)
- Push notification setup (FCM + APNs)
- Generation and scanning of ticket QR codes
- Analytics dashboard for the administrator (number of visitors, average time, load peaks)
- API and architecture documentation
- Staff training on working with the admin panel
- Support for 3 months after launch
Stack: Backend — Node.js + PostgreSQL + Redis + Bull Queue; Mobile — Flutter (or React Native).
| Scope | Timeline |
|---|---|
| MVP: ticket, position, push | 4–6 weeks |
| + Pre-booking, operator workstation | 8–10 weeks |
| + Analytics, multi-office, integration | 14–16 weeks |
| Approach | Speed | Complexity | Latency |
|---|---|---|---|
| WebSocket | High | Medium | 50–100 ms |
| SSE | Medium | Low | 200–300 ms |
| Polling | Low | Very low | 5–10 sec |
Experience and guarantees
We are a team with experience developing mobile applications for queue management systems and the public sector. We have delivered more than 20 projects, including solutions for MFCs and medical centers.
We guarantee stable operation under a load of up to 10,000 concurrent users and compliance with security requirements (data encryption, App Store Review Guidelines).
Order the development of a mobile application for an electronic queue — we will assess your project and propose an architecture. Get a consultation to estimate timelines and cost.