In 2021 I led the development of a queue management system for the City of Ekurhuleni. Five years later it is still in production, running across 20 of the metro's customer care centres. In public sector software, that second sentence is the rare part.
A customer care centre is where a resident walks in to pay an account, log a complaint or sort out a service. On a busy morning, near month end, those centres fill up fast. Without a system managing the flow, you get one queue, no order, and staff who cannot see what is waiting. The queue management system is the layer that turns that into tickets, counters and a board people can actually read, so residents are served in a fair order and the centre can see its own workload.
The real constraint was not the feature list
Building the ticketing logic is the easy part. The hard requirements were the ones that do not show up in a demo. It runs across 20 separate sites, so a problem at one centre cannot take down the others. It has to stay up during the exact peaks when it matters most, when a hall is full of people who took time off work to be there. And it has to keep the ticket, the counter and the display screens agreeing with each other in real time, because the moment those drift apart, staff stop trusting the board and go back to shouting numbers across the room.
The decisions that made it last
The architecture was event-driven. I used Kafka so that every action, a ticket issued, a counter calling the next person, a service completed, flows as an event that each part of the system reacts to. That is what keeps the screens and the counters in step without one central point that everything waits on.
The back end is Java and Spring Boot, the front end for the counters and displays is Angular, and the whole thing runs in Docker containers on Kubernetes, deployed on AWS. The containers matter for the same reason the event model does: each centre runs independently, and the system can be updated or recover a single site without a metro-wide outage.
None of that is exotic. It is deliberately boring, proven technology, chosen because the job was to still be running in five years, not to be interesting for six months.
Why longevity is the metric
Plenty of software gets built and launched. Far less of it is still doing its job half a decade later, especially in the public sector, where systems are often abandoned the moment the project that funded them ends. A system that 20 centres still depend on every working day, years after handover, is the clearest evidence I can offer that the engineering underneath it was sound.
That is the standard I build to now through Samloryx Consultancy: systems that keep working after everyone has moved on to the next thing, because the business still depends on them long after launch day.
If you need software built to last rather than to demo, book a discovery call.