Publish and Subscribe

Module 4 of 7 in the chapter Integration Patterns, chapter 7 of the Integration Architect course. Each module stands on its own. Previous: Salesforce’s Six Patterns, in My Words · Next: Choosing a Pattern

The question this module answers: What is publish and subscribe, and what does it change about how systems depend on each other?

There’s one more pattern you have to know, and it isn’t on Salesforce’s list of six. It’s called publish and subscribe, pub/sub for short, and it lets a system broadcast, and any interested system consume. Publishers publish events. Subscribers subscribe. One event goes out, and it could be delivered to 50 different clients.

It’s a key pattern, and it comes from the industry, not from Salesforce. Enterprise Integration Patterns names it the Publish-Subscribe Channel: “Send the event on a Publish-Subscribe Channel, which delivers a copy of a particular event to each receiver” (Publish-Subscribe Channel (opens in a new tab), Gregor Hohpe and Bobby Woolf, checked 2026-11-01). Salesforce’s guide mentions it as something middleware does, and adds: “Alternatively, this capability can be achieved using the Salesforce event bus with platform events” (Integration Patterns (opens in a new tab), Salesforce Architects, checked 2026-11-01). That event bus is how Salesforce does fire and forget, so you’ve met it already, in module 3.

One Call Each, or One Event for All

At Steve Trucking, a delivery is marked late. Three things need to know: the integration layer, so it can tell Redrock; the coordinator’s screen, so it shows late; and a flow that opens a case for customer care.

The first way: Salesforce calls each one. Three calls, each with its own address, its own credential, and its own handling when it fails. That’s point to point, and you saw where it leads in chapter 5.

Click to enlarge

Frame 1 of 4: one call each.

The second way: Salesforce publishes one event, “this delivery is late”, onto a channel, and moves on. Every subscriber gets its own copy.

Click to enlarge

Frame 2 of 4: one event for all.

Now the part that makes it worth it. Next year, someone wants the late deliveries in a new report, or a new partner wants them too. With point to point, you change Salesforce, again. With publish and subscribe, the new system subscribes, and the publisher never changes.

Click to enlarge

Frame 3 of 4: one more subscriber, and the publisher didn’t change.

Each in Its Own Time

One message in, many messages out. And they don’t all come out at the same moment.

One subscriber gets it immediately. Another is on a little bit of a pause, say the integration layer is down for an hour of maintenance, and picks it up when it reconnects, from where it left off. And someone else might connect 71 hours later, ask for every event still kept, and get it then. The event waits on the bus for each of them. Salesforce keeps high-volume platform events for replay for 72 hours (Integration Patterns (opens in a new tab)), and inside that window, every subscriber gets its copy in its own time.

Click to enlarge

Frame 4 of 4: each in its own time.

Two things follow. First, it’s module 1 again: the publisher got a receipt when the event went on the bus, and that’s all it knows. It doesn’t know who has read it, or when. Second, there’s an edge. A subscriber that’s away for longer than the window misses the event, and nothing tells the publisher. That’s one reason I layer a batch underneath, and module 5 comes back to it. How a subscriber asks for “new only”, “from where I left off” or “everything you’ve kept” is chapter 11.

They Never Have to Coordinate

The beauty is that the publisher doesn’t need to know anything about the subscribers. Process one throws an “account changed” event, and processes three and four respond to it. Someone wrote process one last year. Someone else writes process three today, sees there’s an “account changed” event, and subscribes. They never have to coordinate. That’s loose coupling: the systems are joined by the event, not by each other.

It works inside Salesforce too. Say you’ve built a good error-handling flow: it catches the error, logs it, and notifies someone. Every other flow could call it as a subflow, and every one of them would then depend on it. Or every flow just publishes an “error” event, and the error handler subscribes. Nobody depends on anybody. Chapter 11 (coming soon) has more of these.

One thing to keep straight: each subscriber gets its own copy. That’s different from a queue, where many workers share the messages and each message goes to only one of them. Enterprise Integration Patterns calls that a Point-to-Point Channel, which “ensures that only one receiver will receive a particular message.” Both are useful. They aren’t the same thing.

What Goes in the Event?

Here’s the design question I get every time I teach events. How much do you put in the event?

Click to enlarge

Everything, or a notice.

Everything in the event. The event is self-contained: it has everything the subscriber needs, so it can be acted on without spending API calls going back to the source. But the box is only so big. An event has a size limit (chapter 11 gives it), so you don’t send attachments or big data. And it can go stale. Salesforce keeps high-volume platform events for replay for 72 hours, so a subscriber that was disconnected for 12 hours may read a customer’s name that has changed since.

A notice, with the ID. The event just lets somebody know that something happened, and carries the ID of the record. The subscriber then calls in, say with the REST API, and gets the record, full size and current. Send the box with an ID, and make them come and get it themselves. The cost: every one of those calls back is a call-in, from every subscriber, and each one spends the daily allocation.

Both are in Enterprise Integration Patterns. The notice is close to what it calls a Claim Check: “Store message data in a persistent store and pass a Claim Check to subsequent components.” And it says of events in general that many of them are empty: the fact that they happened is the message.

There’s no one right answer; it’s a fundamental question. Choose per event: how big it is, how fresh the subscribers need it, and how many of them would call back.

A Push That Isn’t Quite a Push

One warning before chapter 11. Publishing an event looks like a push: Salesforce sends, subscribers receive. But look at who opens the connection, the way chapter 5 taught you, and you’ll find it’s the subscriber, connecting in to listen. That’s why so many people draw these arrows the wrong way. Chapter 11 takes it apart.

What an Architect Decides Here

• For every change several systems care about: one call each, or one event for all.
• For every event: its name, so subscribers can find it, and who is allowed to subscribe.
• For every event: everything in it, or a notice with the ID, and so how many calls back it will cause.
• For every subscriber: how long it may be away, and what it does when it’s away longer than the event is kept. A receipt, not the outcome, as module 1 said.

Beyond the exam: what AI changes. An agent can be one more subscriber, added next year without touching the publisher. That’s the strength of the pattern, and it’s also why you keep a list of who subscribes to what, and what each one does with it. And if the agent is sent a notice with an ID, every one of its calls back is a call-in that spends your allocation, the same as any other subscriber’s.

Explore

• Enterprise Integration Patterns, Publish-Subscribe Channel (opens in a new tab), Point-to-Point Channel (opens in a new tab) and Claim Check (opens in a new tab), Gregor Hohpe and Bobby Woolf, checked 2026-11-01.
• Salesforce Architects, Integration Patterns (opens in a new tab): publish/subscribe as a middleware capability, and the event bus, checked 2026-11-01.