What's the difference between the request/reply and publish/subscribe messaging patterns for service-to-service communication, and what coupling trade-off does each impose?

## Two questions a message answers Request/reply and publish/subscribe answer two different questions about a service interaction: **"who is this message for?"** and **"does the sender expect something specific back?"** In **request/reply**, the sender addresses a specific service instance or logical service by name or endpoint, and expects a specific answer shaped by a known contract: - an HTTP `GET` to an orders service returns that exact order; - an RPC to a pricing service returns that exact quote. This holds whether the transport is synchronous, like a blocking HTTP call, or asynchronous, like a message sent to a reply queue tagged with a correlation ID so the response can be matched up later even though the caller didn't block waiting for it. What defines the pattern is not the transport but the addressing: one sender, one intended recipient, one expected reply shape. ## How publish/subscribe flips the addressing Publish/subscribe flips the addressing model entirely. A publisher emits an event, such as `OrderPlaced` or `InventoryAdjusted`, onto a named topic or channel and has no idea, and no need to know, which services are subscribed to it. Zero subscribers, one subscriber, or twenty subscribers can all receive the same event without the publisher's code changing at all. This exists specifically to solve the problem of **fan-out**: in a request/reply world, if the order service needs to notify inventory, shipping, loyalty, and analytics that an order happened, it would have to know about and call all four explicitly, and adding a fifth interested service would require changing the order service's code. Pub/sub inverts that dependency: new subscribers opt in on their own, and the publisher's code and deploy cadence never have to change to accommodate them. ## The coupling trade-off The coupling trade-off is the central thing to understand here. - **Request/reply creates tight, visible coupling.** The caller explicitly depends on the callee's identity, its uptime, and its response contract, and if that contract changes incompatibly, the break is usually immediate and traceable to a specific call site. That visibility is actually valuable for debugging: a failed request/reply call shows up as a clear error with a clear culprit. - **Publish/subscribe creates loose, invisible coupling.** The publisher doesn't depend on any specific subscriber's existence or health, but the system as a whole becomes harder to reason about, because you can no longer look at the publisher's code and know everyone who consumes its output. Two teams can each independently subscribe to the same event and build very different assumptions about what fields mean or how reliably it fires, and neither the publisher nor the other subscriber necessarily knows the other exists. ## How each one breaks In production: | Pattern | What a break looks like | |---|---| | **Request/reply** | Failures are loud and localized: a 500 or a timeout on a specific call, attributable to a specific dependency, is easy to alert on and easy to trace with a distributed tracing tool. | | **Pub/sub** | Failures are diffuse: if a subscriber has a bug that silently drops half the events it receives, there's no error at the publisher, no error at any other subscriber, and the first sign of trouble might be a downstream report weeks later that "loyalty points have been wrong since March." | This is why teams that lean heavily on pub/sub invest in event schemas with versioning discipline, consumer-side dead-letter handling, and often a way to audit which services actually consume which topics, since that knowledge otherwise lives only in each subscriber's own code. ## Where each one shows up A concrete real-world pattern: many e-commerce systems use request/reply for anything the checkout flow needs a direct, synchronous or near-synchronous answer to, such as "is this payment method valid," while using publish/subscribe for everything that happens as a side effect of a completed order, such as: - updating a recommendation engine; - sending a receipt email; - adjusting a fraud-detection model's training data. The order service publishes one `OrderPlaced` event and never has to know that a sixth subscriber, say a new customer-loyalty microservice, was added eight months later; that's the coupling win pub/sub buys. The cost is that if the loyalty service has a bug, nobody automatically finds out from the order service's perspective, because the order service's job was done the moment the event was published.