The city planners of several decades ago were able to map around predictable patterns. Morning rush hour came, evening rush followed, and engineers could smooth out most congestion simply by adjusting traffic light timing at key intersections.
That approach held up just fine when cities changed slowly and traffic was more or less consistent but the modern reality is far messier than that. A single accident, delivery backup, thunderstorm, construction detour, or stadium release can completely reshape traffic flow within minutes. In short the roads have been changing faster than the systems controlling them. A surprising amount of this control is rooted in good old fashioned traffic signals.
The problem can’t just be handled by deciding when a light should turn green. Ideally it should emphasize coordinating huge amounts of live information fast enough to keep traffic systems synchronized with conditions that are constantly changing.
Doing this right means cameras, sensors, IoT systems, weather feeds, navigation data, and traffic telemetry all produce streams of information simultaneously, turning what used to be a traffic engineering problem into something much closer to a real-time computing problem.
As one group of researchers identified recently, the weakness in most traffic systems is that they respond after congestion has already formed. They argue that fixed-time systems just keep cycling through the same patterns even when traffic conditions no longer match the assumptions they were built around.
There has been work in this area already. For instance, adaptive traffic systems improve on this by reacting to sensor data like queue length or vehicle count, but they are still mostly responding to problems after traffic has already started backing up. And the researchers say reinforcement learning models push further by learning from historical patterns, but they still struggle when something unexpected happens (accident, road closure, weather event, event-related surges, etc.).
Cities change in real time, but most traffic infrastructure is still trying to react to what happened a few moments ago rather than anticipating what happens next.
The idea is that instead of treating intersections as isolated control points, the system builds a live digital twin of the traffic network using continuous feeds from cameras, sensors, IoT devices, and edge systems distributed throughout a city.
In this mode, the virtual model is constantly updated with current traffic conditions and used to simulate multiple traffic strategies before anything changes physically at the intersection itself. And rather than reacting directly to congestion after it forms, the system can evaluate how different signal adjustments are likely to affect traffic flow, waiting times, and downstream congestion in real time.
What makes this even more interesting is that the system is not relying on one AI model to control everything, instead it’s different AI agents handling different jobs (one watches traffic, another predicts where congestion might spread, another tests possible traffic strategies inside the digital twin, another explains the reasoning behind the decisions for operators, for instance).
Cameras, sensors, simulations, feature stores, APIs, and control systems are all generating and consuming information at the same time, and most infrastructure was never designed to coordinate that kind of real-time activity cleanly. The difficult part is keeping all the data synchronized fast enough for the decisions to still matter by the time they are made.
Traditional architectures split storage, databases, streaming systems, analytics, and operational control into separate layers connected through constant movement and duplication of data and that creates latency everywhere. By the time information is copied, transformed, queried, and returned to the control system, the conditions on the road may already be different.
This is the exact kind of distributed systems challenge we at VAST increasingly focus on.
A real-time digital twin only works if the underlying platform behaves more like shared, always-current memory across the entire environment, allowing simulation, analytics, reasoning, and action to operate against the same live dataset simultaneously instead of passing data between disconnected systems.
Once you look at these traffic systems as infrastructure problems, the VAST connection becomes pretty clear. The challenge is keeping live sensor data, simulations, event streams, AI systems, and operational controls synchronized fast enough for decisions to still matter while traffic conditions are constantly changing.
Most of the problems here are really distributed systems and real-time data coordination problems. And VAST has multiple elements working in harmony to keep that flowing, including:
DataSpace — A real-time digital twin depends on a shared data plane where telemetry, simulation outputs, sensor feeds, and historical traffic patterns remain continuously current across the environment.
DataEngine — Event handling, orchestration, simulation workflows, and operational actions execute continuously against live infrastructure data.
Kafka-Compatible Event Broker — Traffic infrastructure generates nonstop operational events including congestion spikes, reroutes, incidents, emergency dispatches, and signal updates that need real-time coordination.
DataBase — The digital twin itself becomes a continuously updated operational dataset containing topology, telemetry, prediction outputs, traffic conditions, and simulation results.
Shared Data Architecture — The core systems problem is maintaining low-latency consistency across simulation, analytics, inference, and operational control while conditions constantly change.
AI Operating System Framing — Infrastructure begins coordinating live operational intelligence across physical systems instead of simply storing data for later analysis.
Unified Protocol Access — Traffic systems pull simultaneously from cameras, IoT sensors, GIS systems, routing APIs, weather feeds, and operational databases, creating a massive heterogeneous data integration problem.
Edge-To-Core Coordination — Operational decisions happen at intersections while the broader digital twin maintains city-scale awareness across edge, core, and cloud infrastructure.
Metadata Scalability — Traffic infrastructure produces enormous volumes of small operational events, timestamps, object references, routing relationships, and telemetry updates that must remain queryable in real time.
Vector + Operational Data Together — Prediction, simulation, telemetry, and reasoning workflows increasingly need vector, tabular, event, and object data operating inside the same environment.
Function Execution Near Live Data — Simulation and orchestration layers continuously execute against changing operational conditions without exporting data into separate processing systems.
Operational Auditability — Real-time infrastructure requires explainability, governance, event logging, and operational observability for every automated decision flowing through the system.
The challenge is in this arena (and so many others that are emerging) isn’t simply collecting data or running analytics after the fact, but rather keeping massive amounts of constantly changing information synchronized across sensors, simulations, inference systems, databases, and operational controls fast enough for decisions to happen while conditions are still relevant.
Roads are just one example but we can easily extend this same problem/solution to other complex, ever-changing use cases from power grids and factories to logistics systems, hospitals.
They’re all moving toward architectures where software continuously senses, predicts, simulates, and acts against live operational data, moving toward infrastructure that behaves like a unified, always-active system.
