Study guide
Study guide for chapter 11 of the Integration Architect course. Read the eight modules first; this page helps you check what stuck.
About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.
This chapter is Salesforce’s event bus: who calls whom, what goes on it, how long it waits, and what it costs. It carries choosing the pattern and specifying the right API. The two ideas that unlock the rest: the arrow is reversed (the subscriber calls in), and every outside subscriber is counted.
For the Exam
Section titled “For the Exam”Tick them off as you go. Each one links to where it’s taught.
The reversed arrow (DES-1)
- I know the publisher doesn’t know its subscribers and doesn’t call them: the subscriber connects in, names the channel and says where to start. (Three Ways to Get the News)
- I know the subscriber owns reconnection, catching up and error handling. (Who Does What)
- I draw the arrow from the system that opens the connection, so a subscriber’s arrow points in, though the news goes out. (Why So Many People Get the Arrows Reversed)
- I know Salesforce recommends the Pub/Sub API for new designs, and platform events or Change Data Capture for record changes, not PushTopic or generic events; the Streaming API uses Bayeux and CometD. (Still Outbound, Arrow Pointing In)
The event bus and the Pub/Sub API (DES-4)
- I know platform events are published, not inserted: no record ID to query, and the only way to read them is to subscribe. (Events Aren’t Records)
- I know the Pub/Sub API: gRPC over HTTP/2, binary Avro payloads, and pull-based flow control, where the client says how many it wants. (The Pub/Sub API, “Tell Me Up to 100”)
- I know it supports high-volume platform events and change events, not PushTopic, generic or standard-volume events. (The Pub/Sub API)
- I know Salesforce’s bus is a stream (kept, read by many), not a queue (handed to one worker). (A Stream, Not a Queue)
Platform events and Change Data Capture (DES-1, DES-4)
- I know platform events: you define them (
__e, simple field types, up to 1 MB) and publish them from Flow, Apex or an API. (Platform Events, in Brief) - I know Publish Immediately sends even if the transaction fails; Publish After Commit only after the save. (When It Actually Leaves)
- I know Change Data Capture: select objects, and Salesforce publishes creates, updates, deletes and undeletes; an update carries the changed fields, named in
changedFields. (What a Change Event Carries) - I know gap and overflow events mean “go and look”. (When Salesforce Can’t Send the Whole Change)
- I know custom channels can filter and enrich, and that without an add-on you can select up to five objects. (From a Tsunami to a Stream, Change Data Capture: Just Turn It On)
Replay, retention, order (DES-4)
- I know platform events and change events are kept 72 hours (PushTopic and generic, 24). (How Long They Wait)
- I know the replay options: new only (LATEST, the default), everything kept (EARLIEST, sparingly), or after a stored replay ID (CUSTOM). (Three Places to Pick Up)
- I store replay IDs after handling the event, and never compute them: they’re opaque and not contiguous. (Keeping Your Place)
- I know delivery is at least once (duplicates share an
EventUuid), and order holds within one publish call, not across calls. (What the Subscriber Has to Handle)
Allocations (DES-4)
- I know the two meters: publishing per hour (250,000 in Enterprise and above) and delivery per 24 hours to outside subscribers (50,000 Performance and Unlimited, 25,000 Enterprise). (Two Meters)
- I know deliveries to Apex triggers and flows aren’t counted, and every outside subscriber is. (Inside Is Free, Every Subscriber Counts)
- I know platform events and change events share the delivery allocation. (Every Subscriber Counts)
- I know what happens over each meter: the publish fails and isn’t queued; the subscriber is disconnected. (When You Run Out)
- I can spend fewer deliveries: filtered channels, fewer subscribers, one subscriber that fans out, or the add-on. (Spend Fewer Deliveries)
Events inside the org (DES-1)
- I know a subscriber inside the org runs in its own transaction, asynchronously, with fresh limits, and that it’s the fix for mixed DML. (A New Transaction, Don’t Cross the Streams)
- I know platform event triggers run as Automated Process unless a subscriber configuration sets a user, and receive up to 2,000 events a batch; flows take up to 200 and run as the publisher. (Who the Trigger Runs As, How Many at a Time)
- I know
EventBus.RetryableExceptionresends the batch, andsetResumeCheckpoint()picks up after the last good event. (When the Trigger Fails)
Beyond the bus (DES-1, DES-4)
- I use Salesforce’s bus for events that start or end in Salesforce, and an outside backbone for systems that talk among themselves. (Not on Our Bus)
- I know the bridges: middleware subscribing through the Pub/Sub API, Event Relay to Amazon EventBridge, and a connector to Kafka, each an outside subscriber that’s counted. (Three Bridges)
The contract and the envelope (DES-4)
- I know the publisher owns an event’s contract. (Who Writes the Contract)
- I know AsyncAPI describes event-driven APIs the way OpenAPI describes REST, and CloudEvents standardizes the envelope (
id,source,specversion,type). (The Contract and the Envelope) - I know Pub/Sub API payloads are Avro, with the schema from
GetSchema, and its ID changes when the fields change. (Salesforce’s Own Contract: The Schema) - I know adding a field is usually safe; renaming or removing one breaks subscribers. (A Version Is a Promise, for Events Too)
Beyond the Exam
Section titled “Beyond the Exam”The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.
- Draw the arrow from whoever opens the connection.
- Count deliveries: events times outside subscribers, for the whole org.
- One subscriber, then fan out.
- Plan for zero, once, or three times; in a second or in 71 hours.
- Write down who subscribes to what. The publisher can’t tell you.
- Past 72 hours, have a batch or a resync ready.
- Version events as promises. Add fields; deprecate before you remove.
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| Event bus | Salesforce’s stream of events, kept for a while, read by many |
| Publisher, subscriber | Who puts the news on; who reads it |
| Platform event | News you design, defined as an __e object |
| Change Data Capture | News Salesforce sends when records change |
| Pub/Sub API | The gRPC line outside systems use to publish and subscribe |
| Replay ID | An event’s place in the stream, stored to pick up later |
| At least once | An event may arrive more than once |
| Delivery allocation | Events delivered to outside subscribers in 24 hours |
| Custom channel | A filtered, enriched stream for one subscriber |
| Gap event | “This record changed, go and look” |
| Event Relay | Salesforce sending events to Amazon EventBridge |
| AsyncAPI | The contract for event-driven APIs |
| CloudEvents | The standard envelope on an event |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. On a landscape, someone draws the status events arrow from Salesforce to the integration layer. What's wrong?
The arrow shows who opens the connection. The integration layer subscribes, so the arrow points into Salesforce, though the news goes out. Reread Why So Many People Get the Arrows Reversed.
2. A developer wants to query yesterday's platform events with SOQL. Can they?
No. Platform events are published, not stored as records; the only way to read them is to subscribe, and replay what’s still kept. Reread Events Aren’t Records.
3. A warehouse needs every change to accounts, including fields added next year. Platform event or Change Data Capture?
Change Data Capture: turn it on for Account and Salesforce sends every change, including new fields, without anyone updating a flow. Reread Change Data Capture: Just Turn It On.
4. A flow publishes an event, then a validation rule fails the save. The subscriber still acted on it. Why?
The event used Publish Immediately, which sends whether or not the transaction succeeds. Use Publish After Commit when the event must match a committed save. Reread When It Actually Leaves.
5. The subscriber was down for four days. What can it replay, and what then?
Only the last 72 hours. Everything older is gone from the bus, so it needs a resync or a batch underneath to fill the gap. Reread How Long They Wait.
6. The same status update was processed twice. How does the subscriber guard against it?
Delivery is at least once. Duplicates share an EventUuid, so the subscriber checks it, and makes its writes safe to repeat. Reread What the Subscriber Has to Handle.
7. An Enterprise Edition org has 26,400 status changes a day and three partners subscribed directly. What happens?
79,200 deliveries against 25,000: the subscribers get disconnected. One subscriber (the integration layer) that fans out to the partners, a filtered channel, or the add-on. Reread Every Subscriber Counts.
8. Assigning a permission set and updating an account in the same transaction fails with a mixed DML error. What's an event-based fix?
Publish an event and let a subscriber inside the org do the second save in its own transaction. Reread Don’t Cross the Streams.
Explore
Section titled “Explore”- Salesforce Certified Platform Integration Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam.
- Salesforce Architects, Event-Driven Architecture (opens in a new tab): Salesforce’s decision guide for events.