MuskatGroup / Products
Patient flow, from the queue board to the doctor
An interactive queue demonstration with isolated sessions, a new React interface and a Rust API.
The challenge
Turn the original PatientQueue into a standalone interactive demonstration. Visitors can see the queue, follow a ticket and try the doctor workspace. Every visitor gets an isolated session, so exploring the interface never changes another visitor’s queue.
Three views, one system
The board shows six cabinets, invitations, current appointments and waiting tickets. The patient view presents completed and upcoming stages. The doctor workspace lets visitors choose a cabinet, start and finish appointments and control breaks. Automatic simulation pauses in doctor mode and resumes on returning to the board or patient view.
Eight synthetic tickets follow different journeys, including ordinary stages, screening, alternative consultation cabinets and visit completion. The server considers availability, appointment duration, stage dependencies and breaks. A virtual working day keeps the demonstration available regardless of the actual time.
Modernization
The original two React applications are replaced by a new React, TypeScript and Vite interface. Cabinet cards, typography, layout and mobile views have been redesigned. Russian and English, light and dark themes, a full-screen board and keyboard operation are supported.
The .NET backend is rewritten in Rust with Axum, Tokio, SQLx and SQLite. HTTP, persistence, domain transitions and simulation are separated. OpenAPI describes the contract and generates frontend types.
Isolation and consistency
A server-issued HttpOnly cookie identifies each session. All operations are scoped to that session. Snapshot versions and Idempotency-Key prevent conflicting updates and duplicate commands. Network failures preserve the current view and allow retrying. SQLite restores active sessions after an API restart, and periodic cleanup limits their lifetime.
Administrative screens, clinic schedule imports and real patient data are excluded. Only synthetic tickets are used. This demonstration is not a medical service.
Deployment
Frontend and API live in separate repositories and build independently. A dedicated Compose project connects to the common Caddy through its frontend only. Deployment includes a consistent SQLite backup before migration, paired image/database rollback, external uptime checks and off-host backups.
A public demo link will be enabled after the application is deployed on its own subdomain.
Product interface
