Skip to content
Software Architecture Guide

Publish-Subscribe Pattern

Explanation

Section titled “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

Section titled “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

Section titled “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.

Diagram source 
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

Section titled “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.
Section titled “Related”

Sources

Section titled “Sources”