# Publish-Subscribe Pattern

**In short:** Publish-subscribe lets a sender announce events without knowing who receives them. A broker or event bus copies each event to every interested subscriber. Senders and receivers stay independent, at the cost of latency, weaker ordering, and harder tracing.

## Explanation

In publish-subscribe (often called pub/sub), a sender publishes an event without knowing which consumers will receive it. A middle layer handles delivery. It is usually a message broker or an event bus.

**The elements**

- **Publisher:** the sender. It puts events on one input channel.
- **Subscribers:** the receivers. Each one has its own output channel.
- **Broker or event bus:** the intermediary. It copies each message from the input channel to the output channel of every subscriber that is interested in it.

The channel delivers a copy of each event to each subscriber. See Publish/Subscribe Channel for the messaging view of this idea.

**Why use it**

Without pub/sub, adding or removing a consumer forces a change to the sender. That limits how independently teams can develop and deploy their parts. A broker in between removes this problem. The sender stays unchanged when consumers come and go. This supports modifiability, meaning the system is easier to change.

**How subscribers choose what they get**

- **By topic:** each topic has its own channel, and subscribers pick the topics they want.
- **By content:** the broker inspects each message and delivers it based on what the subscriber asked for.

**Security**

Authenticate and authorize both publishers and subscribers for each topic. Encrypt messages as well. A rogue publisher that injects messages can damage a system as much as a rogue subscriber that reads them.

## Example

An online shop publishes an "order placed" event. A billing service, a warehouse service, and an email service each subscribe to it. Each gets its own copy. Later, the team adds an analytics service as a new subscriber. The shop's ordering code does not change.

## Trade-offs

- **Latency:** the broker adds delay. Pub/sub is a poor fit when consumers need near real-time interaction.
- **Ordering:** subscribers may receive messages in a different order than the sender created them. Subscribers must cope with any arrival order, and the system is less deterministic.
- **Traceability:** decoupling makes the end-to-end flow of a message harder to follow. Correlation IDs help. See Correlation Identifier.
- **Hidden flow:** coupling is low, but the resulting flow is implicit. It is hard to see in the program text.
- **Security effort:** every publisher and subscriber needs per-topic access control.

A publisher sends one event to the broker, which delivers a copy to each subscriber.

```mermaid
flowchart LR
  P[Publisher] -->|input channel| B[Broker / event bus]
  B -->|copy| S1[Subscriber A]
  B -->|copy| S2[Subscriber B]
  B -->|copy| S3[Subscriber C]
```

## Checks

- The document names the broker or event bus that sits between publishers and subscribers.
- The document states whether subscribers select messages by topic or by content filtering.
- Subscribers are designed to tolerate messages arriving in any order.
- Publishers and subscribers are authenticated and authorized per topic, and messages are encrypted.
- Correlation IDs or similar means exist to trace a message end to end.

## Related

- [Publish/Subscribe Channel](https://arc.fuet.ch/concepts/integration/publish-subscribe-channel.md)
- [Broker Pattern](https://arc.fuet.ch/concepts/styles-patterns/broker-pattern.md)
- [Messaging](https://arc.fuet.ch/concepts/integration/messaging.md)
- [Correlation Identifier](https://arc.fuet.ch/concepts/integration/correlation-identifier.md)
- [Loose Coupling](https://arc.fuet.ch/concepts/principles/loose-coupling.md)
- [Modifiability](https://arc.fuet.ch/concepts/quality-attributes/modifiability.md)
- [Message Channel](https://arc.fuet.ch/concepts/integration/message-channel.md)
- [Synchronous vs. Asynchronous Communication](https://arc.fuet.ch/concepts/integration/synchronous-vs-asynchronous-communication.md)

## Sources

- [Publisher-Subscriber Pattern - Azure Architecture Center | Microsoft Learn](https://learn.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber) — learn.microsoft.com, accessed 2026-11-08
- [Publish-Subscribe Channel - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/PublishSubscribeChannel.html) — enterpriseintegrationpatterns.com, accessed 2026-11-08
- [What do you mean by “Event-Driven”?](https://martinfowler.com/articles/201701-event-driven.html) — martinfowler.com, accessed 2026-11-08