Beyond the Bus
Module 7 of 8 in the chapter Events, chapter 11 of the Integration Architect course. Each module stands on its own. Previous: Events Inside the Org · Next: The Contract and the Envelope for Events
The question this module answers: When other systems need events too, should they use Salesforce’s event bus, and if not, how does Salesforce join theirs?
Not on Our Bus
Section titled “Not on Our Bus”Here’s a question I put to every class. What if I have a bunch of outside processes that talk to each other? Process one sends events to process two and process three. None of them are talking to Salesforce. Do I want them on Salesforce’s event bus?
The answer really is no. You don’t want them talking to each other on our event bus.
Everything this chapter has taught says why. Every delivery to an outside subscriber is counted against the org’s allocation (module 5). Events are kept for 72 hours, and no longer (module 4). And the bus belongs to the org, so a team that has nothing to do with Salesforce would be depending on Salesforce’s limits, releases and maintenance.
Put each piece of news on the bus of the system it belongs to, and bridge the few that cross.
So what have people set up instead? An event bus outside Salesforce. The rule I’d write on the landscape: Salesforce’s event bus is for news that starts or ends in Salesforce. Systems that talk among themselves get a backbone of their own. And the few events that cross between the two go over a bridge.
The Backbones Outside
Section titled “The Backbones Outside”The products change; the shapes don’t. Module 2 drew two of them as ideas: a stream, kept and read by many, and a queue, handed to one worker. Add a router, which takes an event and sends it on by rules, and you have the three shapes every backbone offers. Here’s how the ones I meet most often name them, from their own documentation, checked 2026-11-07:
| Shape | Apache Kafka | AWS | Microsoft Azure |
|---|---|---|---|
| A stream, kept and read by many | Kafka itself: topics | Kinesis Data Streams; Amazon MSK (managed Kafka) | Event Hubs, with a Kafka endpoint |
| A queue, one worker each | Queues (share groups), production-ready since 4.2 | SQS (with SNS to send to many) | Service Bus |
| A router, by rules | None built in: consumers or stream processing do it | EventBridge | Event Grid |
Sources: Choosing an AWS application integration service (opens in a new tab), AWS Decision Guides (updated April 16, 2025); Choose between Azure Event Grid, Event Hubs, and Service Bus (opens in a new tab), Microsoft Learn (updated June 12, 2026); the Apache Kafka 4.2.0 release announcement (opens in a new tab) (February 17, 2026). Google Cloud offers the same three shapes under its own names.
Microsoft’s guide puts the difference in one line each: Event Grid for “Reactive event routing,” Event Hubs for “Big data streaming and ingestion,” Service Bus for “Enterprise transactional messaging.” That’s the stream, the router and the queue, in Azure’s words.
Kafka is the common language. Kafka is a really big one, and you’ll meet it everywhere: run by the company itself, or bought as a service. AWS sells managed Kafka as Amazon MSK. Azure’s Event Hubs offers “an Apache Kafka endpoint,” so Kafka applications can often use it “without any code changes” (What is Azure Event Hubs for Apache Kafka? (opens in a new tab), Microsoft Learn, updated February 5, 2026; Standard tier and up). So when someone says “we’re on Kafka,” ask where it runs, but expect the same ideas: topics, partitions, and consumers that keep their own place. A Pub/Sub API subscriber keeps its place the same way, which is why a Kafka team takes to it quickly.
Chapter 18 takes the enterprise backbone further. For this chapter, the decision is the one in the picture above: which bus each piece of news belongs on.
Three Bridges
Section titled “Three Bridges”When an event has to cross, from Salesforce to a backbone or the other way, something has to carry it. These are the three bridges I see most.
Middleware subscribes, Event Relay sends, a connector subscribes: three ways across.
Middleware Subscribes
Section titled “Middleware Subscribes”This is a very common pattern, and it’s the one for Salesforce end to end. MuleSoft subscribes to the event bus, gets the stream of events, and pushes each one on to where it has to go: an ERP such as SAP, a partner, a warehouse.
The nice thing about middleware subscribing is what it leaves out of Salesforce. Your processes inside Salesforce don’t need a flow or trigger that makes a callout. They publish the event and move on. I call it a light drag on Salesforce processing. Very light. And everything module 1 gave the subscriber, the connection, the reconnection, the error handling, belongs to the middleware, which is built for it.
MuleSoft’s own guidance for new work is its Salesforce Pub/Sub Connector, “based on the Pub/Sub API” (Processing Events with Salesforce Connector 12.0 (opens in a new tab), MuleSoft Documentation, checked 2026-11-07). The same page has two warnings worth knowing on any middleware. Run the subscriber on more than one node, and it can cause “duplicate event consumption.” And when Salesforce moves an org, a stored replay ID can stop working (module 4).
At Steve Trucking, this is what the integration layer does: one subscriber, then a webhook to Redrock, a file to Keystone, EDI to Brightwave (module 5).
Event Relay to Amazon EventBridge
Section titled “Event Relay to Amazon EventBridge”In Setup, Salesforce has its own bridge: Event Relay. You set up a relay, point it through a named credential at AWS, and Salesforce sends the events itself. Salesforce Help says: “Use Event Relay to send platform events and change data capture events from Salesforce to Amazon EventBridge” (Event Relay (opens in a new tab), Salesforce Help, checked 2026-11-07). From EventBridge, AWS’s rules send them on to AWS services and partners. And events can come back: an EventBridge API destination publishes an event to Salesforce through the REST API.
Notice the arrow. With Event Relay, Salesforce starts the call, so Salesforce runs the bridge for you. Nobody outside has to keep a line open. It’s the one bridge in the picture that’s set up in Setup.
One correction to how I said it in class: Event Relay goes to one place, Amazon EventBridge. It isn’t a bridge to Kafka. To reach Kafka, use one of the other two bridges.
Event Relay carries custom high-volume platform events, real-time event monitoring events and change events, not standard platform events (Event Type, Size, and Features (opens in a new tab), Salesforce Help, checked 2026-11-07). And like any bridge outside, its deliveries are counted against the allocation (module 5).
A Kafka Connector
Section titled “A Kafka Connector”For Kafka, the usual bridge is a connector that subscribes to Salesforce through the Pub/Sub API and publishes to a Kafka topic, and one that does the reverse, reading a topic and publishing events to Salesforce. Kafka Connect is Kafka’s own framework for these, and connector makers offer ones for Salesforce. Because Event Hubs speaks Kafka, the same bridge can reach Azure.
Whoever runs the connector runs the subscriber. Everything in module 4 applies: it stores its replay ID, handles repeats, and someone is told when it falls behind.
The Size Gap, Dated
Section titled “The Size Gap, Dated”Here’s a good example of why every number in this course has a date.
Salesforce’s page says: “The maximum event message size that Amazon EventBridge supports for incoming and outgoing events is 256 KB. If an event message larger than 256 KB is relayed from Salesforce to EventBridge, the event isn’t delivered to EventBridge” (Event Type, Size, and Features (opens in a new tab), checked 2026-11-07).
AWS’s page says that on January 29, 2026, “AWS has raised the maximum payload size from 256 KB to 1 MB for… Amazon EventBridge” (More room to build: serverless services now support payloads up to 1 MB (opens in a new tab), AWS Compute Blog, checked 2026-11-07).
Both are official, and both are dated. Until Salesforce’s page changes, design relayed events to stay under 256 KB, the smaller number, because that’s what Salesforce documents for its bridge. A platform event can be 1 MB (module 3), so an event that’s fine on the bus may not cross the relay. Send the ID, not the whole package, and you’ll rarely be near either number.
And What About the Older Doors?
Section titled “And What About the Older Doors?”You’ll still find older ways onto the bus in older orgs: the Streaming API with CometD, PushTopic events and generic events. Salesforce’s own guidance points new work to the Pub/Sub API (module 2). Where they came from, and how to plan their retirement, is chapter 17.
Test knowledge. Use Salesforce’s event bus for events that start or end in Salesforce, and an outside backbone (Kafka, or a cloud’s event services) for systems that talk among themselves. Know the bridges: middleware such as MuleSoft subscribing through the Pub/Sub API and pushing on (no callouts from Salesforce); Event Relay, set up in Setup, sending platform events and change events to Amazon EventBridge (and back through an API destination); a connector to Kafka. Every outside bridge is an outside subscriber, counted against the delivery allocation.
Watch it on video
Section titled “Watch it on video”In early 2024 I made a video on the patterns: events inside Salesforce, outside subscribers, and a bridge to Kafka. The note under the video says what’s still right and what’s changed since.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- Which bus each piece of news belongs on: Salesforce’s for what starts or ends in Salesforce; a backbone outside for systems that talk among themselves.
- The backbone, if there isn’t one: a stream, a queue or a router, by what the traffic needs, and where it runs.
- The bridge for each event that crosses: middleware, Event Relay, or a connector, and who runs it.
- Who owns each bridge’s subscriber duties: the replay ID, the repeats, the alerts.
- The size each crossing event is designed to, by the smaller documented limit, dated.
- Every bridge in the delivery count, with the rest of module 5’s arithmetic.
Explore
Section titled “Explore”- Event Relay (opens in a new tab) and Event Type, Size, and Features (opens in a new tab): Salesforce Help (checked 2026-11-07)
- More room to build: serverless services now support payloads up to 1 MB (opens in a new tab): AWS Compute Blog, January 29, 2026 (checked 2026-11-07)
- Choosing an AWS application integration service (opens in a new tab): AWS Decision Guides (checked 2026-11-07)
- Choose between Azure Event Grid, Event Hubs, and Service Bus (opens in a new tab) and What is Azure Event Hubs for Apache Kafka? (opens in a new tab): Microsoft Learn (checked 2026-11-07)
- Apache Kafka 4.2.0 Release Announcement (opens in a new tab): Apache Kafka, February 17, 2026 (checked 2026-11-07)
- Processing Events with Salesforce Connector 12.0 (opens in a new tab): MuleSoft Documentation, and the Pub/Sub Connector it points to (checked 2026-11-07)