Skip to main content

Messaging (Pub / Sub)

1. Concept Overview​

Publish / Subscribe (pub / sub) is a messaging pattern used to send data between parts of a system without direct coupling.

In a pub / sub system, producers publish messages and consumers subscribe to receive them. Producers and consumers do not communicate directly. The only shared agreement is the topic name.

Pub / sub exists to solve one problem:

Deliver the same message to multiple independent consumers without coordination.

2. How to Think About It​

Think of pub / sub like this:

  • Publishers send messages
  • Subscribers receive messages
  • Messages are sent to a named channel called a topic

Important mental model points:

  • Publishers do not know who is subscribed
  • Publishers do not know how many subscribers exist
  • Subscribers do not know who published the message
  • Subscribers process messages independently
  • Publishing does not wait for subscribers to finish handling messages

The publisher and subscriber are decoupled in both time and implementation.

3. What Happens Step by Step​

At a high level, pub / sub works like this:

  1. A publisher sends a message to a topic.
  2. The messaging system receives the message.
  3. The messaging system delivers the message to all subscribers of that topic.
  4. Each subscriber processes the message independently.

That is the entire model.

There is no coordination between subscribers and no feedback loop to the publisher.

4. Guarantees​

A pub / sub system provides the following general guarantees:

  • Messages published to a topic are delivered to all subscribers of that topic.
  • Each subscriber receives its own copy of the message.
  • Subscribers process messages independently of each other.

Any guarantees beyond these depend on the specific pub / sub implementation.

5. What This Does Not Do​

Pub / sub does not:

  • Guarantee exactly-once execution
  • Enforce ordering across different topics
  • Coordinate work between subscribers
  • Act as a workflow engine
  • Track processing state

Pub / sub is a delivery pattern, not a control mechanism.

6. Correct Ways to Use This​

Pub / sub works best when:

  • Events need to be broadcast to many consumers
  • Consumers are independent of each other
  • Producers should not depend on consumer behavior
  • Systems need to evolve without tight coupling

Common use cases include:

  • Event notifications
  • Activity streams
  • Telemetry and metrics
  • State change signals

7. Common Mistakes​

Treating pub / sub like a queue​

Pub / sub delivers messages to all subscribers, not just one.
If you need load balancing, pub / sub is the wrong tool.

Encoding workflows into pub / sub​

Pub / sub does not enforce sequencing or completion.
Retries and failures will break workflow assumptions.

8. When This Is the Wrong Tool​

Pub / sub is the wrong choice if you need:

  • Exactly-once execution
  • Strict processing order across consumers
  • Job scheduling or background work
  • Transactional guarantees

In those cases, consider:

  • Queues
  • Workflow engines
  • Databases
  • Application-level coordination

The Core Idea​

If you remember one thing:

Pub / sub delivers messages to interested parties without direct coordination.

RelayX implements this pattern with explicit, documented rules so you can rely on it in production.



Need Help?

Join our Discord server, post your concern & someone from our team will help you out ✌️