Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Publish/subscribe (pub/sub) messaging is an asynchronous pattern in which a publisher sends a message to a topic or intermediary, and messaging infrastructure routes it to subscribers that have expressed interest. The publisher does not need to know who those subscribers are or where they run.
How pub/sub messaging works
Pub/sub separates the component that produces a message from the components that consume it. A broker, router, or other messaging infrastructure tracks subscriptions and distributes matching messages.
- A subscriber registers: It expresses interest in a topic, channel, or matching filter.
- A publisher sends a message: The publisher associates its message or event with a topic or sends it to the intermediary.
- The infrastructure routes it: The broker or router selects matching subscriptions and delivers the message.
The topic or channel identifies a category or stream of messages. Depending on the system, subscriptions may match by topic, filter, or other routing rules. The pattern commonly supports one-to-many delivery, but exact routing and delivery behavior depends on the implementation.
Example: an order event with several consumers
Suppose an order service publishes an order-placed event. Inventory, fulfillment, and analytics services can each subscribe to that event and receive it through the messaging infrastructure. The order service need not know the identities or endpoints of those consumers. A new subscriber can be added independently rather than requiring the publisher to send it a separate direct call.
#1 Best Overall
What pub/sub is useful for
Pub/sub is useful when an event should notify multiple components, when follow-up work can happen asynchronously, or when one event can trigger several workflows. It can support broadcasts without requiring a real-time reply and allow independent components to scale or change without being tightly connected to one another.
Topic- or content-based filtering can help deliver relevant messages to different subscribers. These benefits describe the pattern; they do not guarantee a particular system’s capacity, delivery speed, or reliability.
How pub/sub differs from queues and request-reply
Pub/sub and queues
A queue commonly holds work until it is processed, with a consumer taking responsibility for a message. Pub/sub is commonly used to distribute a publication to multiple interested subscribers. Products can combine or blur these models, so check how the chosen service handles delivery, retention, and consumer responsibility rather than relying on its label alone.
Pub/sub and request-reply
Publishing is generally asynchronous: the sender does not automatically receive a synchronous answer. If the sender must wait for a response, use a request-reply design with a defined response path. Pub/sub can notify other components of an event, but it is a poor fit for a workflow that requires an immediate, strongly consistent answer from every receiver.
What pub/sub does not guarantee
The pattern alone does not ensure that every subscriber is online or receives every message. Messages may be transient, delivery may be delayed, and subscribers may process them at different times. A delay can leave a subscriber’s view of system state temporarily different from another component’s view—an example of eventual consistency.
If subscribers need to recover work after disconnecting, check whether the implementation provides persistence, retention, replay, acknowledgements, and retries. Also establish how it handles duplicates, message expiry (TTL), and ordering; these behaviors vary across systems.
Rank #4
Questions to ask when choosing an implementation
- Delivery: What guarantees are offered? Are acknowledgements and retries available, and how should consumers handle duplicate messages?
- Ordering: Are messages ordered globally, per topic, or per key? Does the application actually require an ordering guarantee?
- Recovery: How long are messages retained? Can a disconnected subscriber replay missed messages, and when do messages expire?
- Routing: What fan-out capacity and topic or content filters are supported? How are subscriptions created and managed?
- Security: How are publishers and subscribers authenticated and authorized, and how is message data protected in transit and at rest?
- Operations: What latency, workload scale, operational effort, and cost should the system support?
These are implementation comparison points, not features that every pub/sub service necessarily provides. Check the selected system’s documentation and guarantees against the needs of the application.
MQTT is one example, not another name for pub/sub
MQTT is a protocol that uses the pub/sub pattern; pub/sub itself is a broader messaging pattern. The OASIS MQTT Version 5.0 Standard, published on 7 March 2019, describes MQTT as a client-server publish/subscribe messaging transport protocol designed for contexts that include constrained environments. It defines three quality-of-service levels: at most once, at least once, and exactly once. Those are MQTT-specific specification details and should not be assumed of other pub/sub systems.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
