Request/Response vs Publisher/Subscriber

Recently I am using Zenoh to write a library for creating microservices in C++. The Library provides the same communication patterns as Zenoh. When creating a service chosing the right pattern can make big difference on system design. Here’s what I learned about when to use each approach.

Publisher/Subscriber Pattern

This is asynchronous communication - service publishes event and other services subscribe to events they care about. Publisher doesn’t know who (if anyone) will receive the event. Subscribers process events at their own speed.

Use Pub/Sub when you want to decouple services and don’t need immediate response. Robot navigation is good example - when robot reaches waypoint, mapping service updates map, task scheduler assigns next task, telemetry service logs position, fleet manager updates robot status. Each service handles its part independently, and if one service is down, others continue working.

Pub/Sub is great when one event triggers multiple actions. It also handles different processing speeds well - some services might process events immediately while others batch them for efficiency. The system becomes more resilient because services don’t directly depend on each other.

Sync Request/Response Pattern

This is synchronous communication - service A calls service B and waits for response. It is similar to function calls but over network. Request/Response works well when you need immediate feedback and the operation should complete before continuing.

Use Request/Response when you need immediate result from another service. Safety system validation, obstacle detection queries, or getting current robot pose are good examples. The calling service needs to know success or failure right away to decide next step. Also works well for simple operations where you’re just retrieving or updating robot configuration data.

The downside is tight coupling and availability dependency. If service B is down, service A cannot complete its operation. You also need to handle timeouts, retries, and circuit breakers to deal with network issues. Latency adds up when you chain multiple synchronous calls together.

Async Request/Response Pattern

This is middle ground between sync request/response and pub/sub. Service A sends request to service B but doesn’t wait for immediate response. Service B processes request and sends response back later via callback.

Use async request/response for long-running operations where you need eventual response but can’t wait synchronously. Path planning computation, SLAM map building, or sensor calibration are good examples. You get decoupling benefits like pub/sub but still get direct response back to requester.

The challenge is matching responses back to original requests. Also more complex than sync calls because you need to handle response delivery and potential failures in response path.

How to Choose Between Them

Here’s simple decision notes I use:

Use Sync Request/Response when:

• You need immediate response (safety checks, pose queries)
• Operation is simple and fast (< 100ms)
• Failure should stop the flow immediately
• You’re doing simple robot configuration operations

Use Async Request/Response when:

• Operation takes long time but you need eventual response
• You can’t wait synchronously but need confirmation later
• Processing is complex but requester needs result

Use Pub/Sub when:

• You don’t need response back
• One event should trigger multiple actions
• Services can work at different speeds
• You want maximum decoupling and resilience

The Real Trade-offs

Sync Request/Response: Simple to understand and debug, immediate feedback, but tight coupling and cascading failures.

Async Request/Response: Decoupled execution with eventual response, but complex correlation and error handling.

Pub/Sub: Maximum decoupling and resilience, great to trigger multiple actions, but harder to debug and no direct feedback.

Most real systems use all three patterns. The key is choosing right pattern for each specific interaction based on your consistency, latency, and coupling requirements.