How We Built a Monitoring System for Modern Toll Collection

The toll collection system consists of a complex network of applications that constantly communicate with one another. All requests, responses, and events within the applications leave traces that must be captured, stored, and displayed in a meaningful way in real time. This was the challenge we tackled together with a client in the toll collection industry.

When a system outgrows itself

The client had been using a monitoring system that we implemented about ten years ago. What was the reason the old system was no longer sufficient? Searching through older data had become limited, partly due to the sheer volume of data; for example, records older than two months were no longer directly accessible and required manual retrieval from the archives. Under heavy loads, the system’s stability noticeably decreased, and retaining data for one year or more—as required by both operations and regulators—became too great a challenge.

Although the original design was solid (the system had been in operation for 10 years!) and served its purpose well, technology has advanced. That is precisely why we didn’t opt for incremental fixes, but instead carried out a comprehensive overhaul.

Architecture for reality, not for ideal conditions

Our task was to set up a system designed for continuous operation, an area in which we have considerable experience from other industries as well. That is why the new system is based on a Kubernetes infrastructure with a GitOps approach, which we manage using Argo CD. This is a set of tools that we now use as standard for most of our projects.

Based on this, the key components function as follows:

·      Apache Kafka for reliable data capture and streaming

·      Elasticsearch for storage and fast search

·      Prometheus for system health monitoring

There are two data streams.

The first stream consists of application logs, i.e., records generated by individual applications. The second stream is the integration log, which captures communication between systems. Every request and every response is logged. Both streams travel through data pipelines to Elasticsearch, where they are indexed and become immediately available for analysis.

Why high availability requires more than just redundancy

One of the key requirements was high availability, as the system must operate without interruption. That is why we set it up with geo-redundancy across three locations. Two are physical data centers, while the third is a virtualized location that can be moved as needed. This setup is not random.

Kubernetes requires a majority quorum to operate reliably. If one location fails, the remaining two maintain quorum and the system continues running. With only two locations, this is not possible—if one goes down, the system stops because there is no majority.

During testing of the relocation of the third location, the transition was completely seamless. The system behaved as if nothing had happened.

When testing the failure of a single location, the system also continued to operate without interruption—albeit with reduced capacity—but users did not notice any outage. Once the location was brought back online, the system automatically returned to full operation without any administrator intervention.

This demonstrates that such an architecture works in practice as intended.

How we ensured traceability and control

Today, the client uses the system to monitor and analyze the performance of their applications. The most common use case is troubleshooting, as the team can quickly identify the root cause of anomalies, verify user complaints, or analyze errors in backend systems.

Since requests and responses are stored together and properly indexed, a complete view of a single event can be assembled within seconds. It is clearly visible where the issue occurred, which application was involved, and what its response was. The system also includes fine-grained access control, ensuring that data is visible only to authorized users.

There is a clear improvement compared to the previous system. The system remains stable even under heavy loads, searches are fast regardless of the age of the data, and the user interface includes customized dashboards that the operations team actually uses. The solution we have implemented is not an isolated case, but rather a reflection of a broader trend in the tolling industry. System operators around the world are investing in real-time data processing solutions, which are primarily used for advanced analytics. 

Sophisticated analytics are becoming increasingly important, such as fraud detection through license plate analysis and vehicle behavior patterns, dynamic pricing based on traffic conditions, and predictive infrastructure maintenance. The common thread among these approaches is the ability to reliably capture, store, and analyze large volumes of data in real time, without compromising on availability or security.

What does the new data infrastructure enable?

The infrastructure we have built is both an upgrade of the legacy system and a foundation for future development. Once the system reliably processes data in real time, new possibilities emerge—analyzing patterns over time, detecting subtle anomalies, and predicting traffic flows.

This is the true advantage of modern data infrastructure. We have created a system that not only performs reliably but also enables a shift in how data is approached and used. We designed it to grow alongside the client’s ambitions.