Request-Reply Pattern

The defining characteristic of the request-reply pattern is its synchronous nature. The client sending the request blocks its execution thread and waits for the corresponding reply message from the server. This creates a direct, conversational flow ideal for operations that require an immediate, deterministic response, such as querying a robot's current battery level or requesting permission to enter a restricted zone. The blocking behavior simplifies client logic but ties client availability to server response latency.

This pattern creates a tight temporal coupling between the client and server. Both systems must be available and responsive at the exact moment of the exchange for the interaction to succeed. This makes the pattern less resilient to network partitions or server failures compared to asynchronous patterns. In a fleet context, this coupling is acceptable for low-latency, critical control commands but problematic for long-running operations that would stall the requesting agent.

Request-reply is inherently a point-to-point communication model. Each request is directed at a specific recipient (the server), and the reply is routed back to the single originating client. This contrasts with the one-to-many model of the publish-subscribe pattern. In fleet orchestration, this is used for direct agent-to-orchestrator queries (e.g., "Agent 23, what is your status?") or for an agent to call a specific microservice, like a path planning API.

A correlation ID (or message ID) is a crucial implementation detail. This unique identifier is attached to the outgoing request and is included in the corresponding reply. It allows the client to match incoming replies to their original requests, especially when multiple asynchronous requests may be in flight or when using connection pools. Without correlation, a client cannot determine which request a reply belongs to, leading to application logic errors.

The pattern is implemented over various transport protocols, each with trade-offs:

• HTTP/1.1 & HTTP/2: The web's dominant request-reply protocol. gRPC builds on HTTP/2 for high-performance RPC.
• Direct TCP/UDP Sockets: Used in custom binary protocols for ultra-low latency within controlled environments.
• MQTT (with QoS 1 or 2): While primarily pub/sub, MQTT can emulate request-reply using a pair of topics (e.g., request/agent01 and reply/agent01) and a correlation ID in the payload.
• AMQP: Supports request-reply via temporary, exclusive reply-to queues.

The pattern is best suited for operations requiring an immediate, authoritative answer. Examples in a heterogeneous fleet include:

• Command Acknowledgement: "Move to coordinate X,Y" → "Acknowledged" or "Failed".
• State Query: "What is your current load weight?" → "15 kg".
• Lock Acquisition: "Request exclusive access to workstation 5" → "Lock granted with token ABC".
• Service Discovery Lookup: "Resolve the endpoint for the 'path-planner' service". It is poorly suited for event notifications (use pub-sub) or long-running tasks (use async patterns with callbacks).

gRPC is a modern, high-performance Remote Procedure Call (RPC) framework that is ideal for low-latency, synchronous request-reply communication between orchestration servers and agents. It uses HTTP/2 for transport and Protocol Buffers (Protobuf) for efficient binary serialization.

• Key Features: Built-in streaming, strong typing via .proto files, and support for deadlines/timeouts.
• Use Case: Directly calling a path planning service on an Autonomous Mobile Robot (AMR) to request a new trajectory, expecting an immediate confirmation or error.

HTTP with a RESTful architectural style is the most ubiquitous implementation of request-reply. It uses standard verbs (GET, POST, PUT) over TCP/IP.

• Key Features: Human-readable (often JSON), cacheable, and universally supported.
• Use Case: A fleet management dashboard sending a POST /api/v1/agents/{id}/stop command to an agent's onboard API and waiting for a 200 OK response.
• Limitation: Higher overhead than binary protocols, making it less ideal for ultra-high-frequency telemetry.

While MQTT is inherently a publish-subscribe protocol, it can emulate request-reply using correlated topics and Quality of Service (QoS) levels.

• Mechanism: The client publishes a request to a topic (e.g., fleet/agent_01/command/request), subscribing to a dedicated reply topic (e.g., fleet/agent_01/command/response/{correlationId}).
• QoS 1 (At Least Once) or QoS 2 (Exactly Once) ensure the request and reply are delivered despite unreliable networks.
• Use Case: Sending a non-critical configuration update to a manually operated vehicle with a poor cellular connection, ensuring eventual confirmation.

Advanced Message Queuing Protocol (AMQP) provides robust, queued request-reply through its RPC over queues pattern.

• Mechanism: The client sends a message to a server's request queue, specifying a reply_to queue. The server processes the message and publishes the response to the designated reply queue.
• Key Features: Guaranteed delivery, transactional support, and sophisticated routing via exchanges.
• Use Case: A mission-critical task assignment from the central orchestrator to a specific robot, where guaranteed, in-order processing and a formal acknowledgment are required.

The Data Distribution Service (DDS) standard includes a Remote Procedure Call (RPC) protocol designed for deterministic, real-time systems.

• Key Features: Extremely low latency, Quality of Service (QoS) policies for reliability and deadlines, and data-centric design.
• Use Case: A real-time collision avoidance system requesting immediate sensor fusion data from a nearby agent to calculate an evasive maneuver, with a hard deadline for the reply.

Request-reply has two primary implementation flavors with critical concurrency implications.

• Blocking Synchronous: The client thread is blocked until the reply is received or a timeout occurs. Simple but inefficient for high-throughput systems.
• Non-Blocking/Async: The client sends the request and registers a callback or uses a future/promise. The thread is freed to handle other work, and the callback is invoked when the reply arrives.
• Orchestration Impact: Async request-reply is essential for an orchestrator managing hundreds of agents without spawning a thread per agent, preventing resource exhaustion.

A messaging paradigm where senders (publishers) categorize messages into topics without knowledge of the receivers (subscribers). Subscribers express interest in one or more topics and only receive relevant messages. This enables decoupled, asynchronous communication, ideal for broadcasting fleet-wide state updates (e.g., a new zone restriction) or event notifications where multiple agents need the same information simultaneously.

• Contrast with Request-Reply: Pub/Sub is one-to-many and push-based, while request-reply is strictly one-to-one and pull-based.
• Use Case: A central orchestrator publishes a "workspace map updated" event; all path-planning agents subscribe and receive the new layout without individual requests.

A lightweight, publish-subscribe network protocol designed for efficient machine-to-machine communication in constrained environments. It is a common transport layer for implementing both pub/sub and request-reply patterns in IoT and robotic fleets.

• Key Features: Minimal packet overhead, support for Quality of Service (QoS) levels, and persistent sessions.
• In Orchestration: Often used for telemetry data (battery levels, sensor readings) via pub/sub, while request-reply over MQTT can be implemented using correlated topic pairs (e.g., fleet/agent_01/request, fleet/agent_01/reply).

Defines the delivery guarantees for a message in a networked system. Crucial for ensuring the reliability of request-reply interactions in unreliable environments like wireless robot fleets.

• QoS 0 (At-Most-Once): Fire-and-forget; minimal overhead. Risk of loss.
• QoS 1 (At-Least-Once): Guarantees delivery, but may cause duplicates. Requires idempotent operations on the server.
• QoS 2 (Exactly-Once): Guarantees delivery exactly once. Highest overhead, ensures no duplication—critical for non-idempotent commands like "dispense item."

A resilience pattern that prevents a client from repeatedly attempting a request that is likely to fail. It monitors for failures and, when a threshold is exceeded, "trips" the circuit to fail fast, allowing the downstream service (e.g., a robot's onboard computer) time to recover.

• States: Closed (normal operation), Open (requests fail immediately), Half-Open (testing if service is recovered).
• Orchestration Context: Protects the central planner from being overwhelmed by retries when an agent is offline or malfunctioning, enabling graceful degradation and real-time replanning to reassign tasks.

A unique identifier attached to a request message and included in its corresponding reply. It is essential for tracing the flow of a transaction across asynchronous boundaries and decoupled services.

• Purpose: Allows a client to match replies to specific requests when responses may arrive out-of-order. Enables distributed tracing and debugging.
• Example: An orchestration server sends 100 simultaneous task assignment requests, each with a unique correlation ID. As robots accept tasks, their replies use the same ID, allowing the server to correctly update its task allocation map.