Message Bus

Producers and consumers do not need to be online simultaneously. The message broker stores messages until consumers are ready, enabling temporal decoupling. This prevents cascading failures—if the Task Decomposition Engine is slow, the Agent Driver can still publish status updates without blocking. Key benefits:

• Producers fire-and-forget commands
• Consumers process at their own pace
• System resilience under variable load

Messages are routed to multiple consumers based on topic subscriptions rather than direct addressing. An agent publishing a fleet.agent.status event doesn't know which services consume it—the Schema Registry ensures all subscribers understand the payload. This enables:

• One-to-many fan-out without code changes
• Dynamic addition of new monitoring services
• Loose coupling between Fleet Health Monitoring and State Synchronization

Messages are written to disk before acknowledgment, ensuring zero data loss during broker restarts or consumer failures. Configurable retention policies—by time or storage size—allow replay of historical events for Event Sourcing architectures. This is critical for:

• Rebuilding Digital Twin state after a crash
• Auditing command sequences for safety investigations
• Debugging with full message history

Message buses provide configurable delivery guarantees to match use-case criticality:

• At-most-once: Fire-and-forget for telemetry where loss is acceptable
• At-least-once: Commands are redelivered until acknowledged, using Idempotency Keys to prevent duplicate execution
• Exactly-once: The strongest guarantee, essential for financial transactions or irreversible physical actions like charging station docking

When consumers cannot keep pace with producers, the bus applies backpressure to prevent memory exhaustion and crashes. Mechanisms include:

• Consumer prefetch limits that cap unacknowledged messages
• Broker-side throttling when queue depth exceeds thresholds
• Signaling slow consumers to the Fleet Management System for load redistribution This prevents the Command Queue from overflowing during peak operational surges.

Within a single partition or queue, messages are delivered in the exact order they were published. This FIFO guarantee is essential for sequential command execution—a lift command must arrive before a move command. For parallel processing across partitions, ordering is relaxed to maximize throughput. The bus allows configuring:

• Partitioning keys (e.g., agentId) to group related messages
• Strict ordering for Saga Pattern orchestration steps

A messaging paradigm where senders (publishers) categorize messages into topics without knowledge of receivers. Subscribers express interest in specific topics and receive only relevant messages. This decouples producers from consumers, enabling dynamic scaling. In fleet orchestration, a robot's telemetry publisher can broadcast position data to a topic like /fleet/position, while a monitoring dashboard and a collision avoidance system independently subscribe without direct coupling.

A modular software component that translates data formats and command structures between disparate messaging standards. It enables a ROS 2-native robot to communicate with an MQTT-based warehouse system through the message bus. The adapter handles:

• Wire protocol translation (e.g., TCP to WebSocket)
• Message serialization (e.g., Protobuf to JSON)
• Quality of Service mapping between protocols This is essential for heterogeneous fleet orchestration where no single protocol dominates.

A centralized service that stores and governs the data contracts for all messages traversing the bus. It enforces backward compatibility by validating that new message versions do not break existing consumers. Common implementations like Confluent Schema Registry support Avro, Protobuf, and JSON Schema. In a fleet system, a schema change to a TaskAssignment message must be registered and versioned to prevent a legacy AGV driver from failing on unexpected fields.

An architectural pattern where all state changes are captured as an immutable sequence of events on the message bus. Instead of storing only the current fleet state, the system persists every AgentAssigned, TaskCompleted, and BatteryLow event. This provides:

• A complete audit trail for post-incident analysis
• The ability to replay events to reconstruct state at any point in time
• A foundation for CQRS (Command Query Responsibility Segregation) patterns

A flow-control mechanism that prevents a fast producer from overwhelming a slow consumer on the message bus. When a subscriber's processing buffer reaches capacity, it signals upstream to reduce throughput. Techniques include:

• Reactive Streams specifications (e.g., RSocket)
• TCP window resizing at the transport layer
• Explicit acknowledgment protocols like AMQP credit-based flow control Without backpressure, a burst of telemetry data from a 100-robot fleet can cause out-of-memory crashes in downstream analytics services.

A specialized message queue that stores events that could not be successfully processed after a configured number of retry attempts. Messages are routed here when:

• The payload fails schema validation
• A consumer repeatedly returns a poison message error
• Processing exceeds a time-to-live threshold Operators monitor the DLQ to diagnose systemic issues, such as a misconfigured agent driver that cannot parse a new command format, preventing message loss while enabling debugging.