Publish-subscribe definition
Publish-subscribe (pub/sub) is a messaging pattern in which senders, called publishers, emit messages to a named topic or channel instead of to specific recipients, and receivers, called subscribers, register interest in that topic and are delivered every matching message. An intermediary broker handles routing, so publishers and subscribers never need to know about each other.
Publish-subscribe messaging is a way for software components to exchange events without addressing each other directly: a publisher writes a message to a topic, and every subscriber to that topic receives a copy. Content systems use the same shape. In Sanity, publishing a document emits an event that webhooks and Functions subscribe to, so a search index, a cache purge, and a Slack notification can each react to the same change without the editor's tooling knowing any of them exist.
Publish-subscribe messaging works through an intermediary that sits between the sender and the receivers. A publisher sends a message to a named topic (sometimes called a channel or a subject) held by a broker, the broker looks up which subscribers have registered interest in that topic, and it delivers a copy of the message to each of them.
The publisher gets no list of recipients and no reply. It does not know whether there are zero subscribers or two hundred, and it does not wait for them to finish processing. That property is called decoupling, and it is the whole point of the pattern: you can add a fourth consumer of an event without editing the code that produces the event.
Most brokers also support some form of filtering so a subscriber can narrow what it receives. Topic-based filtering matches on the channel name, often with wildcards, so a subscriber might take `orders/eu/*`. Content-based filtering inspects the message body or its attributes, so a subscriber might take only messages where the order total is above a threshold. Amazon SNS documents both styles under message filtering.
The difference between publish-subscribe and a message queue is how many consumers get each message. In publish-subscribe, one message is fanned out to every subscriber of the topic. In a traditional point-to-point queue, one message is consumed by exactly one worker, and the queue exists to distribute work rather than to broadcast news.
That difference follows from what each pattern is for. Publish-subscribe suits notification: an order was placed, and billing, inventory, email, and analytics all need to know. A queue suits task distribution: a thousand thumbnails need generating, and it does not matter which of ten workers takes each one, only that each thumbnail is generated once.
The two patterns are frequently combined. A common arrangement is a topic that fans out to several queues, one per consuming service, so each service gets its own copy of every message and can work through its backlog at its own pace. AWS describes this as the fanout pattern, with SNS handling the publish-subscribe layer and SQS holding the per-consumer queues.
Publish-subscribe is used wherever one event needs to trigger several independent reactions. Ecommerce checkout is the canonical example: a single "order placed" message reaches the payment service, the warehouse system, the customer email service, and the analytics pipeline, each of which acts on it without coordinating with the others.
Other common uses include live dashboards and price tickers pushing updates to connected browsers, internet-of-things fleets where thousands of devices publish sensor readings that several backend consumers read, chat and collaboration features where a message posted to a room is delivered to everyone present, and cache invalidation where a change event tells edge caches which entries to drop.
Content operations belong in this list too. When a product page changes, the search index needs re-indexing, the CDN needs purging, a translation job may need queuing, and a downstream storefront may need rebuilding. Publish-subscribe lets each of those be a separate subscriber to one publish event, which means adding a fifth consumer later is a configuration change rather than a rewrite of the publishing step.
Delivery guarantees in publish-subscribe describe how hard the broker tries to get each message to each subscriber, and there are three standard levels. At-most-once means a message may be lost but is never duplicated. At-least-once means a message is never lost but may arrive more than once, usually because the broker retried before it saw an acknowledgment. Exactly-once means each message is processed a single time, which is the hardest to provide and usually depends on the consumer cooperating.
The MQTT specification formalizes these as quality-of-service levels 0, 1, and 2, described in the OASIS MQTT 5.0 standard. Most general-purpose cloud brokers default to at-least-once.
The practical consequence for anyone building a subscriber is idempotency: write your handler so that receiving the same message twice produces the same result as receiving it once. Usually that means recording a message or event ID and ignoring repeats, or making the operation naturally repeatable, such as setting a value rather than incrementing it. Ordering deserves the same caution, because many brokers guarantee order only within a partition or a message group, not across a whole topic.
The trade-off of publish-subscribe is that the decoupling which makes the pattern useful also makes the system harder to reason about. Because a publisher has no list of its subscribers, nothing in the publishing code tells you what actually happens when an event fires. Answering "what breaks if I change this message" becomes an exercise in searching subscription configuration rather than reading a call stack.
Other costs come with it. The broker is a new dependency that has to stay available and be paid for. Debugging spans several services, so distributed tracing and a shared correlation ID stop being optional. Message schemas become a public contract, and changing a field can break a consumer you forgot existed, which is why teams often version their event payloads and add fields rather than renaming them. Failed messages need somewhere to go, typically a dead-letter queue that holds anything a subscriber could not process.
None of that argues against the pattern, but it does argue against reaching for it by default. In our experience, publish-subscribe pays off when several genuinely independent things must react to the same event, or when you expect to add consumers over time. When one service calls one other service and needs an answer back, a direct request is simpler and easier to debug.
Unlock New Possibilities with Sanity
With publish-subscribe under your belt, it's time to see what Sanity can do for you. Explore our features and tools to take your content to the next level.
Last updated: