Pub Sub Messaging: Mermaid Flowchart Diagram

About Source

Publish-subscribe (pub/sub) messaging is a pattern in which message publishers send messages to named topics or channels without knowing who will receive them, and subscribers declare interest in specific topics to receive all messages published to them.

Pub/sub decouples producers from consumers at the identity level. A publisher addresses a topic, not a service. Any number of subscribers can listen to that topic and each receives an independent copy of every message. Adding or removing subscribers requires no changes to publishers — the system is open for extension without modification.

The matching between publishers and subscribers is managed by a broker or message bus. In RabbitMQ, a fanout exchange implements pure pub/sub. In Kafka, multiple Kafka Consumer Groups reading the same topic achieve pub/sub semantics with replay capability. In Redis, the native PUBLISH/SUBSCRIBE commands (explored in Redis PubSub Flow) offer a lightweight, in-memory option.

The critical distinction from a simple message queue is fan-out: in a queue, a message is consumed by exactly one worker (the Competing Consumers Pattern). In pub/sub, the same message is delivered to every subscriber independently. This makes pub/sub ideal for broadcasting state changes — a price update delivered to all connected clients, or an OrderPlaced event delivered to both the inventory service and the analytics service simultaneously, as shown in Fan Out Messaging.

The trade-off is that subscribers must be active to receive messages in many implementations (Redis pub/sub is entirely in-memory with no persistence). Durable pub/sub — where messages survive subscriber downtime and can be replayed — requires a log-structured broker like Kafka or a managed service like Google Cloud Pub/Sub.

Frequently asked questions

Publish-subscribe (pub/sub) messaging is a pattern where publishers send messages to named topics without knowing who will receive them, and subscribers declare interest in specific topics to receive every message published to them. The broker manages the matching and delivery. Adding or removing subscribers requires no changes to publishers, making the system open for extension without modification.

A publisher sends a message to a topic on the broker. The broker forwards an independent copy of that message to every active subscriber registered for that topic. In RabbitMQ a fanout exchange implements this. In Kafka, multiple consumer groups reading the same topic achieve pub/sub semantics. In Redis, the `PUBLISH`/`SUBSCRIBE` commands provide a lightweight in-memory variant.

Use pub/sub when a single event needs to be broadcast to multiple independent services simultaneously — price updates to all connected clients, a domain event consumed by both an analytics service and a notification service. It is the correct choice when the number of consumers is not known at publish time and each consumer needs its own copy of the message.

In a message queue, a message is consumed by exactly one worker — multiple consumers split the messages between them (the competing consumers pattern). In pub/sub, the same message is delivered to every subscriber independently. A message queue is designed for distributing work; pub/sub is designed for broadcasting state changes. Many systems combine both: a pub/sub topic fans out to multiple queues, each with competing consumers for parallel processing.

mermaid

flowchart LR
    PUB1[Publisher: Weather Station A] -->|publish| T1[Topic: weather-updates]
    PUB2[Publisher: Weather Station B] -->|publish| T1
    PUB3[Publisher: Price Feed] -->|publish| T2[Topic: price-updates]

    T1 -->|copy per subscriber| SUB1[Subscriber: Dashboard App]
    T1 -->|copy per subscriber| SUB2[Subscriber: Alert Service]
    T1 -->|copy per subscriber| SUB3[Subscriber: Data Archiver]

    T2 -->|copy per subscriber| SUB4[Subscriber: Trading Bot A]
    T2 -->|copy per subscriber| SUB5[Subscriber: Trading Bot B]
    T2 -->|copy per subscriber| SUB3

    subgraph Broker[Message Broker]
        T1
        T2
    end