Realtime product engineering
theSwiftLine
A real-time queue product for waiting somewhere else.
Waiting should not require standing still
theSwiftLine began with a familiar community problem: the only way to know your turn was close was to remain physically inside a disorganized queue. The product lets people join remotely, track position, and receive updates while organizers control how the line moves.
The supplied résumé records more than 1,500 users. The public backend grounds the rest of this case study.
Two paths to current state
Position, queue activity, and service events move to connected clients.
Durable PostgreSQL records remain available when a live connection is stale or reconnecting.
This separation matters because a socket is a delivery channel, not the source of truth. The backend associates connections with queue users, handles disconnects, and calculates position from active line records. Push subscriptions provide another path for front-of-queue and position notifications.
Queue position is a product decision
The service calculates an effective position after accounting for the number of staff serving. Estimated wait begins with the event's average service time and can incorporate the bundled ML.NET estimator. The product also supports pause state, automatic skips, anonymous joining where enabled, and optional geographic restriction.
- Identity
- JWT access plus refresh tokens, with anonymous accounts available by policy.
- Delivery
- SignalR for live state and Web Push for background attention.
- Operations
- Structured Serilog output and background jobs for queue, account, and email work.
- Verification
- Service tests cover queue detail, position, pagination, and event behavior.
Where uncertainty remains
Realtime delivery can lag, disconnect, or arrive after a user has changed state. ETA is an estimate, not a promise. The design therefore gives durable server state priority and treats live updates as an acceleration layer.
The repository contains health-check components, but the current startup path leaves their registration and endpoints disabled. The case study does not present them as an operating capability.
Tradeoff: broadcasting updates and push notifications improves immediacy but creates fan-out work on each queue change. A larger deployment would need tighter batching and explicit delivery limits. No unsupported scale claim is made here.