QueueSync

01

From a specific problem to a product

02

One shared real-time workflow

QueueSync separates the flow into check-in, the staff view and the waiting person's status. New entries, status changes and call-ups are available to the clients involved immediately.

1. 01

   Check-in

   Staff can add people directly. For publicly accessible instances, self check-in by QR code is also available.

2. 02

   Staff view

   The current queue, open items and call-ups are coordinated on shared or personal devices.

3. 03

   Waiting status

   People can follow their ticket number, position and call-up on their own phone.

All three perspectives operate on the same current state.

03

Different use cases

The data and status model represents a general queueing process. The following use cases are examples, not fixed product boundaries.

1. Walk-ins & visitor flows

   Organize guests and visitors without requiring a conventional ticket machine.

2. Hospitality & entry

   Coordinate people waiting and trigger call-ups from a central view.

3. Leisure & attractions

   Organize capacity-limited offers through a virtual queue.

4. Events & service areas

   Represent temporary or permanent waiting processes in a structured way.

QueueSync represents the process, not a particular industry.

04

Hosted or local appliance

I designed QueueSync not just as a web application, but as an operable product. Depending on the use case, it runs as a hosted instance or as a local QueueSync Appliance on site.

1. Hosted

   A dedicated instance per site can make check-in and waiting status publicly accessible when required.

   • Site-isolated data and configuration
   • Reproducible operation with Docker Compose
   • Self check-in and mobile status view

2. QueueSync Appliance

   The application runs on the site's local network and keeps operational data on site.

   • Local data storage and site isolation
   • Automated backups and a defined restore procedure
   • Reproducible setup, device protection and straightforward replacement

Both operating models are built from the same product base.

05

Built for day-to-day operations

Beyond the core workflow, I implemented the functions that become relevant on shared devices and in daily operations.

1. Device protection

   Authorize operational devices by PIN and revoke them individually or together.

2. Admin & analytics

   Manage settings, opening hours, daily statistics, the event log and connected clients centrally.

3. Team messages

   Exchange short notes between operational views.

4. Announcements

   Make scheduled groups and notes visible to staff in advance.

5. Daily close

   Automate backups, daily statistics and log rotation.

6. Self check-in

   People join by QR code and follow their own queue status.

06

Technical guardrails

The architecture keeps user interfaces, application logic and operations separate without making local deployment unnecessarily complex.

• 01Real-time synchronization across clients using Server-Sent Events instead of polling
• 02Separation of the React frontend, FastAPI API and SQLAlchemy data model
• 03Containerized, reproducible operation with Docker Compose
• 04Hosted and appliance deployments from the same product base
• 05A dedicated instance and data store for each site
• 06Automated SQLite backups, daily close and log rotation
• 07Responsive self-service interfaces and short paths on shared devices
• 08Separate device and admin authentication with revocable device tokens