Publish-Subscribe Pattern

The defining feature of pub/sub is loose coupling between message producers (publishers) and consumers (subscribers). Publishers categorize messages into logical channels, called topics or events, without knowledge of which subscribers, if any, exist. Subscribers express interest in one or more topics without knowledge of the publishers. This spatial and temporal decoupling allows components to be developed, deployed, and scaled independently, which is critical for heterogeneous fleets where robot types and software modules evolve at different rates.

Pub/sub architectures inherently support horizontal scaling. New subscribers can be added to a topic without any configuration changes to publishers or existing subscribers. This is essential for fleet orchestration where the number of agents (subscribers to command streams) or monitoring dashboards (subscribers to status streams) can change dynamically. The messaging infrastructure (broker) manages the fan-out of messages, allowing the system to scale to thousands of concurrent connections. For example, adding a new autonomous mobile robot to the fleet simply involves having it subscribe to the relevant command topic.

Communication is fundamentally asynchronous. Publishers send messages and continue processing without waiting for subscribers to receive or process them. This non-blocking behavior is key for real-time systems like fleet control, where a central planner must issue commands without being delayed by the individual response times of each robot. The pattern enables an event-driven architecture, where the flow of the system is determined by events such as task_completed, obstacle_detected, or battery_low. Subscribers react to these events as they occur, enabling responsive and resilient system behavior.

Message routing is based on a topic namespace. A topic is a string that identifies a category of information (e.g., fleet/robot_12/telemetry or warehouse/zone_a/navigation_alerts). Subscribers receive only messages published to topics they are interested in. This provides efficient, selective data distribution. In a mixed fleet, different message types can be segregated: autonomous robots might subscribe to high-frequency lidar/processed topics, while manual forklifts might only receive dispatch/assignments. This filtering happens at the broker, preventing unnecessary network traffic and processing load on subscribers.

Pub/sub systems implement configurable Quality of Service (QoS) levels that define delivery guarantees. These are crucial for operational reliability:

• At-most-once: Best-effort delivery; messages can be lost. Useful for high-volume, non-critical telemetry.
• At-least-once: Guaranteed delivery, but duplicates are possible. Essential for critical commands like emergency_stop.
• Exactly-once: The strongest guarantee, ensuring no loss or duplication. Used for transactional state updates, like inventory_count_modified. The pattern allows different semantics per topic or even per message, letting system designers balance performance against reliability for each data flow.

It is often contrasted with the point-to-point or message queuing pattern. In a queue, messages are persisted and delivered to one consumer. Once consumed, the message is removed. Pub/sub delivers each message to all interested subscribers. Queues are ideal for distributing tasks among a pool of identical workers (e.g., processing pick lists). Pub/sub is ideal for broadcasting events or state changes to multiple interested parties (e.g., notifying all monitoring systems that a robot has entered a restricted zone). Many enterprise systems, including fleet orchestrators, use a hybrid of both patterns.

The request-reply pattern is a synchronous messaging pattern where a client sends a request message and blocks until it receives a corresponding reply from a server. It contrasts with the asynchronous nature of publish-subscribe.

• Used for direct commands and queries, such as a central orchestrator instructing a specific robot to cancel its current task.
• Often implemented over RPC frameworks like gRPC or via message queues using correlation IDs.
• Critical for operations requiring an immediate, deterministic response within a fleet, complementing the event-driven flow of pub/sub.

Quality of Service levels in messaging systems define the contractual guarantee for message delivery between a sender and a receiver. They are crucial for ensuring system reliability in dynamic environments.

• At-most-once (QoS 0): Message is delivered once at best; loss is acceptable. Used for non-critical telemetry.
• At-least-once (QoS 1): Message is guaranteed to arrive, but duplicates may occur. Common for task assignments.
• Exactly-once (QoS 2): Message is delivered precisely once. Required for idempotent financial transactions or state-changing commands within an orchestration platform.