All projects
CompletedPrivate codebaseWeb App

Smart Queue Management System

A queue system for service centres: reception issues numbered tokens with wait estimates, counters call customers in strict FIFO order with spoken announcements, a public display board updates live, and admins get audit-backed reports.

JSON API endpoints
18
Database tables
8
Staff roles + public board
3
Live board refresh (configurable)
5s

Highlights

  • Collision-free daily token numbering, even with several receptionists
  • Two counters can never call the same customer, thanks to row locks
  • Live display board and spoken announcements without WebSockets
  • Every token transition recorded for reporting and audit

The problem

Queues at banks, clinics and government offices are often manual, unfair and opaque. Customers don't know how long they'll wait, staff can't see the load, and managers have no data. This system automates the whole flow: issuing tokens, calling customers fairly, showing the queue, and reporting on performance.

It was built as my final-year project, Development of a Smart Queue Management System for Service Centers.

What it does

  • Reception issues a token per service type (for example A-001) with an estimated wait time, and prints a receipt.
  • Counters open a session, call the next customer in FIFO order, and mark tokens as serving, completed or skipped. Calls are announced aloud using the browser's speech synthesis.
  • Display board shows the live queue on a TV or kiosk, refreshing at an interval admins can configure.
  • Admins manage users, counters, service types and which counters serve which services, and see a live dashboard and reports.

Architecture

System architecture
  1. Clients
    • Reception
    • Counter
    • Admin
    • Public display board
  2. Middleware
    • Session & idle timeout
    • Role check
    • CSRF
  3. API
    • Queue
    • Admin
    • Board
    • Reports
  4. Services
    • Auth
    • Tokens
    • Queue (FIFO & wait estimate)
    • Reports
    • Config
  5. Data
    • MySQL (tokens, counters, audit log)

Engineering challenges

1

Unique token numbers under concurrency

Token numbers reset daily per service type. A sequence table keyed by service and date is incremented atomically inside a transaction, so two receptionists issuing tokens at the same moment can never get the same number.

2

Two counters calling the same customer

"Call next" runs in a transaction that locks the oldest waiting token for the counter's services (SELECT … FOR UPDATE). The second counter waits for the lock and gets the next customer instead.

3

Live updates on shared PHP hosting

WebSockets aren't available on typical shared hosting, so the display board and dashboards poll lightweight JSON endpoints at a configurable interval. It's simple, robust and cheap to run.

4

Security in plain PHP

A middleware chain handles sessions with idle timeout, role checks and CSRF tokens. Passwords use bcrypt, the session ID is regenerated on login, all queries use prepared statements, and internal folders are blocked from direct web access.

Results

The system is complete, with ER, use-case and architecture diagrams, and was delivered as my final-year project.

Next project

AkorLabs Website & Blog