Pub/Sub

Pub/Sub, short for publish-subscribe, is a messaging pattern in which publishers send messages to named topics without any knowledge of which subscribers, if any, will receive them, and subscribers express interest in topics and receive every matching message. A broker in the middle handles routing and delivery. This deliberate decoupling of senders from receivers is what lets systems scale, add consumers, and fail independently without rewiring the producers.

• Topic-based routing - Messages are published to topics or channels, and the broker fans them out to all interested subscribers.
• Producer/consumer decoupling - Publishers and subscribers never reference each other directly, so either side can change without touching the other.
• Asynchronous delivery - Work is handed off as messages rather than blocking request/response calls, smoothing spikes and load.
• Many-to-many fan-out - A single event can reach any number of subscribers, the core mechanic behind event-driven architectures.

In real API operations, Pub/Sub is the pattern behind webhooks, streaming APIs, and event-driven backends — where a single business event, like an order placed, is published once and consumed by billing, fulfillment, and analytics independently. It is the asynchronous counterpart to request/response REST, and it is what standards like AsyncAPI exist to describe. As estates lean harder on real-time and agentic workloads, the publish-subscribe seam becomes a governance surface of its own — channels, message schemas, and delivery guarantees that need documenting and controlling just like synchronous endpoints do.