Before learning a solution, it helps to feel the problem it was built to solve.

Direct communication does not scale

Imagine a weather station that measures temperature every minute. A mobile app wants this reading. So does a farming dashboard, a news ticker, and a research database. The simplest approach is for the weather station to call each of these programs directly, one by one, every single minute. This works fine with three or four listeners. But what happens when fifty new apps want the same reading? The weather station’s code must be changed every time someone new wants to listen, and it must remember the exact address of everyone it talks to.

Software engineers call this kind of arrangement tight coupling, meaning two programs are so directly wired together that a change in one forces a change in the other. Tight coupling makes systems fragile and hard to grow, because the sender must always know the full list of receivers, and the whole system can slow down if any one receiver is slow to respond.

What we actually want

What most systems really need is a way to announce “something happened” without caring who is listening, how many listeners there are, or what they plan to do with the news. The sender’s job should end the moment it shares the information. This is exactly what the publish-subscribe model provides.

The pattern in one sentence, and then in plain words.

A short definition

The publish-subscribe model, often shortened to pub-sub, is a messaging pattern in which senders, called publishers, send messages without knowing who will receive them, and receivers, called subscribers, express interest in certain kinds of messages without knowing who sent them. A go-between, usually called a broker or message bus, sits in the middle, collecting messages from publishers and forwarding them to every matching subscriber.

In everyday terms, a publisher shouts an announcement into the air, the broker hears it and knows who has asked to be told about announcements like that one, and each interested party receives a copy. The publisher never learns who received it, and subscribers never learn who else is listening.

Where the idea comes from

The pattern grew out of much older ideas in computing, such as the observer pattern used inside single programs, where one part of an application notifies other parts when something changes. As software systems grew from single programs into networks of many separate services, the same notify-whoever-is-interested idea was extended across machines and the network, giving rise to dedicated pub-sub systems. Today the pattern shows up everywhere, from small mobile apps to the backbone of the largest technology companies in the world.

Five words explain most of the pub-sub pattern. Learn these and the rest becomes easy.

Why the broker matters so much

The broker is what makes the whole pattern work without publishers and subscribers ever needing each other’s contact details. It keeps track of who is subscribed to what, receives every published message, and takes on the job of delivering it to the right places. Without a broker, publishers would be back to calling every subscriber directly, which is the exact problem pub-sub was built to avoid.

flowchart LR
  P1[Publisher: Weather Station] --> B
  B --> S1[Subscriber: Mobile App]
  B --> S2[Subscriber: Farming Dashboard]
  B --> S3[Subscriber: News Ticker]
        

Without topics, every subscriber would drown in messages meant for someone else.

Grouping related messages

A real system publishes many different kinds of messages. An online shop might publish order updates, payment confirmations, and stock level changes, all at the same time. If every subscriber received every message, most of it would be irrelevant noise. Topics solve this by giving each kind of message a name, so a subscriber can choose exactly what it wants to hear about.

Two common ways to filter

There are generally two styles of filtering. In topic-based filtering, messages are published to a named channel, such as “orders” or “payments”, and subscribers pick the channels they care about, receiving everything sent to that channel. In content-based filtering, subscribers describe the kind of message they want using conditions, such as “only orders over one hundred dollars”, and the broker checks each message’s content against every subscriber’s conditions. Topic-based filtering is simpler and far more common, while content-based filtering is more powerful but more demanding for the broker to compute.

Follow a single message from the moment it is born to the moment it is read.

sequenceDiagram
  participant Pub as Publisher
  participant Br as Broker
  participant S1 as Subscriber A
  participant S2 as Subscriber B
  Pub->>Br: Publish message to topic "orders"
  Br->>S1: Deliver copy
  Br->>S2: Deliver copy
  S1-->>Br: Processed independently
  S2-->>Br: Processed independently
        

There are two ways a subscriber can actually receive its messages.

Push delivery

In push delivery, the broker actively sends messages to subscribers the moment they arrive, without waiting to be asked. This feels instant and is simple for the subscriber, but it means a slow or overwhelmed subscriber can be flooded with messages faster than it can handle them.

Pull delivery

In pull delivery, subscribers ask the broker for new messages whenever they are ready. This gives subscribers control over their own pace, since nothing arrives faster than they request it, but it introduces a small delay between a message being published and a subscriber actually noticing it, depending on how often it asks.

Networks and machines fail sometimes, so pub-sub systems let you choose how strict to be about delivery.

Three common promises

When a message travels from a publisher to a subscriber, three outcomes are possible. At-most-once delivery means the message might be lost along the way but will never be delivered twice. At-least-once delivery means the message is never lost, but it might occasionally be delivered more than once if something goes wrong and a retry happens. Exactly-once delivery means the message is neither lost nor duplicated, which is the hardest promise to keep and usually the most expensive to guarantee.

Pub-sub is not the only way programs can send each other messages. Seeing it next to the alternatives makes it clearer.

Point-to-point queues

In a point-to-point queue, a message sent by a producer is delivered to exactly one consumer, even if several consumers are listening. This is useful for distributing tasks among a group of workers, where you want each task handled once and only once. Pub-sub is the opposite: a message is delivered to every interested subscriber, not just one.

Request-response

In a request-response pattern, one program directly asks another a question and waits for a direct answer, similar to a phone call. This requires both sides to know about each other and to be available at the same time. Pub-sub removes both requirements: publishers do not wait for a reply, and subscribers do not need to be online at the exact moment a message is published, if the broker is designed to hold messages for them.

No pattern is free of cost. Knowing the trade-offs helps you use pub-sub wisely.

Because a broker often carries sensitive business information, protecting it matters.

A broker you cannot see is a broker you cannot trust.

Good habits to copy and bad habits to avoid when using pub-sub.

Helpful patterns

Habits to avoid

The pattern quietly powers a huge amount of the software people use every day.

Practical lessons that save teams from painful surprises.

Best practices

Mistakes beginners often make

Not quite. A classic queue usually delivers each message to exactly one consumer. Pub-sub delivers each message to every subscriber interested in that topic, so the two solve different problems.

Not necessarily. If the broker is designed to hold messages for a while, a subscriber that starts later can still receive messages published earlier, depending on how the system is configured.

Yes. A single program can publish to some topics and subscribe to others at the same time, which is common in larger systems built from many cooperating services.

The publisher still sends its message successfully, since it never checks who is listening. Depending on the system, the message may simply be discarded if there is nobody to deliver it to.

No. Small applications use it too, often through lightweight in-app libraries, whenever different parts of an app need to react to the same event without being tightly wired together.

A callback usually connects two specific pieces of code directly. Pub-sub adds a broker in between, so any number of unrelated listeners can react to the same event without the publisher knowing about any of them individually.

Yes. Subscribing and unsubscribing are meant to be easy and safe operations that do not affect the publisher or any other subscriber.

The publish-subscribe model is a messaging pattern that lets programs share information without ever needing to know each other directly. Publishers announce messages to named topics, a broker takes on the job of tracking interest and delivering copies, and subscribers receive only the messages they have chosen to care about. This decoupling makes systems easier to grow, since new subscribers can be added without touching the publisher, and it supports the many-to-many communication that modern software increasingly depends on. Like every pattern, it comes with trade-offs around reliability, ordering, and delivery guarantees that are worth understanding before relying on it. Used thoughtfully, publish-subscribe gives teams a simple, flexible way to build systems that stay loosely connected and ready to grow.