Beyond gRPC: The Data Distribution Challenge in Physical AI Systems

In the course of supporting modern autonomous vehicles, robotic fleets, and mission-critical defense platforms, today’s Physical AI systems generate massive volumes of sensor data that must be processed, analyzed, and acted upon in real time. But that’s only the beginning. Across industries, efficient real-time data streaming is now the key competitive differentiator – and getting it right can unlock new insights and system-wide capabilities. For example, if your development team is tasked with building the infrastructure to support Physical AI, just how critical is low latency?

While traditional cloud-native applications can tolerate a few seconds of latency here and there, those types of data gaps are quite frankly unacceptable for Physical AI systems. Instead, these types of autonomous systems demand deterministic, millisecond-level responsiveness across geographically distributed deployments. Plus, the challenge intensifies when data must traverse heterogeneous network environments, from bandwidth-constrained edge devices to high-capacity cloud infrastructure, while still maintaining strict reliability, security, and temporal guarantees. This is the moment when you need a real-time data streaming platform with more options and more flexibility.

Autonomous technology is evolving rapidly. As a result, we are already seeing a significant shift in how these systems are designed. Initially, developer teams tended to gravitate toward a microservice architecture to manage the complexity of autonomous agents, such as drones or self-driving tractors. In these environments, gRPC understandably became a very popular choice due to its efficiency in cloud-native applications and its ability to define service interfaces clearly using protocol buffers. However, as we push these systems into the "Edge" – where network connectivity is flaky and real-time predictability is non-negotiable – it’s become abundantly clear that gRPC was neither built for or capable of handling the heavy lifting required for a high-performance data plane.

Defining the Control Plane and the Data Plane

When discussing the architecture of autonomy platforms, it’s useful to reflect on the two distinct communication planes that drive them:

• The Control Plane: This manages orchestration, configuration, and specific commands. It is primarily a request-reply pattern where you might query an agent for its available resources or tell a vehicle to follow a specific path.
• The Data Plane: This is dedicated to distributing the actual state of the world. It involves a continuous flow of information, such as kinematic state (position and velocity), telemetry updates, and live video feeds from onboard cameras.

Where Does gRPC Hit a Wall?

At first glance, it seems like a perfect fit. With gRPC, you can send commands, request information, and build clean interfaces between components. But as systems grow more dynamic, something subtle starts to break down.

The reason? Not all communication in an autonomous system is the same. Control plane communication is calm, structured, and transactional. Whereas data plane communication is constant, high-volume, and time-sensitive. Treating them the same way leads to friction.

Traditionally, message-centric architectures such as gRPC were designed for simple cloud-based request-response patterns, where centralized services handle discrete transactions. However, message-centric architectures fundamentally struggle with the continuous, high-velocity real-time data streams that drive Physical AI.

In order to make gRPC behave like a real-time data stream, you have to bend it a bit – using streaming calls to simulate a publish-subscribe model. It works, but it comes at a cost:

• Every connection has to be explicitly managed
• Systems need extra logic just to discover each other
• Resource usage grows quickly as more nodes join
• Handling disconnects becomes complicated and fragile

None of this is obvious on a small scale. But once you move beyond a handful of devices, the architecture starts to feel heavy. It’s not that gRPC is failing – it’s that it’s being asked to do something it wasn’t designed for. The result is increased latency, reduced throughput, and fragile coupling between components that cannot scale to meet the demands of real-time autonomy.

DDS: A System Designed for the Data

This is where a different approach enters the picture: Data Distribution Service (DDS^®). Instead of focusing on services calling each other, DDS focuses on the data being shared.

Imagine you're managing a fleet of tractors. In a DDS-based system, each tractor doesn’t need to know who’s listening. It simply publishes its state. Anyone who cares – another tractor, a control system, a monitoring tool – can subscribe and receive updates automatically. That shift changes everything.

There’s no need to wire up connections between every pair of systems. No need to track who’s online. No need to rebuild state after a disconnect. The system becomes less about endpoints and more about information flowing through a shared space.

Let’s stay with tractors for a moment. Say they’re moving across a field, avoiding each other, adjusting their paths, and occasionally heading off to recharge. Each one is streaming its position, status, and intent. A control console can step in at any time, redirecting a tractor or pausing the entire fleet. That type of system can be built three different ways:

• Using only gRPC, every tractor needs to maintain connections to every other tractor and to the control system. As the fleet grows, so does the complexity – more connections, more threads, more coordination logic.
• With a hybrid approach, gRPC handles the commands, while DDS takes over the continuous data sharing. Suddenly, much of the complexity disappears. The tractors simply publish their state, and the system stays in sync naturally.
• With DDS alone, even the command layer becomes part of the same unified system. Discovery is automatic. Data persists. New participants can join and instantly understand the current state of the world.

The difference isn’t just technical – it’s architectural. One approach fights the nature of the system. The other embraces it.

Conclusion: Choosing the Right Tool for the Job

This isn’t about replacing gRPC. It’s about using it where it fits – and recognizing where it doesn’t.

• If your system is mostly request-response and lives in the cloud, gRPC is a strong choice.
• If you’re dealing with continuous, real-time data across many distributed nodes, you’ll likely need something more.
• And if you’re building truly dynamic systems, a hybrid – or fully data-centric – approach starts to make sense

Today’s Physical AI systems require guaranteed delivery and temporal ordering without relying on centralized brokers that introduce single points of failure. Security must be integrated at the data distribution layer rather than bolted on through network perimeter defenses. These requirements demand a fundamentally different architectural approach – one centered on data rather than messages.

Want to learn more about how to design scalable systems that can meet the demands of real-time autonomy and Physical AI? Delve deeper into this topic with an on-demand webinar entitled “Beyond gRPC: Architecting a Real-Time Data Plane for Autonomous Systems.”

And don’t miss the other installments of our blog series on real-time data streaming.

About the author:

Bob Leigh, Senior Director of Commercial Markets, RTI

Bob has been matching market needs and emerging technology for over 20 years as an entrepreneur and technology leader. He has spent his career in small companies and is the founder of two. At each venture he led the charge to create new technologies for emerging markets and disruptive applications. Since joining RTI, Bob has led the development of new commercial markets by understanding the important market trends of the day, and figuring out how RTI’s expertise and technology can be applied to solve these challenges.