Pattern First, Then Mechanism
Module 1 of 7 in the chapter Choosing the Right Integration Design, chapter 16 of the Integration Architect course. Each module stands on its own. Previous chapter: Integration Orchestration · Next: Salesforce’s Decision Guide, Read Well
The question this module answers: Once you know an integration’s pattern, how do you choose the mechanism that builds it, and why in that order?
Two Words in One Breath
Section titled “Two Words in One Breath”When I teach fire and forget, I say it like this: “Fire and forget is where you make a request and you don’t need the answer… Platform events… Once the event goes out, you’re done.”
Notice what’s in that sentence. Two different things. Fire and forget is a pattern: what kind of conversation the two systems have. A platform event is a mechanism: one of the ways Salesforce can have that conversation. It isn’t the only one. A callout from a background job is fire and forget too, and so is an outbound message.
People mix the two up all the time, and it costs them. “We’re using platform events” doesn’t tell me the design. “Salesforce tells the other systems and doesn’t wait” does. The first is a choice of parts. The second is the architecture, and it leaves the parts open until you know enough to choose.
The Order to Think In
Section titled “The Order to Think In”The Data Architect course sets out the order, in my class words, and I won’t repeat it all here: Requirements, Then Pattern, Then Mechanism. In short:
- The requirements. Who starts it, which way the data goes, how soon, how much.
- The pattern. Salesforce’s six names, chosen with three questions and the selection tables (chapter 7 module 5).
- The mechanism. The doors in and out of Salesforce that Part 2 of this course took one at a time.
Part 1 ended at step 2: Checkpoint 1 named a pattern for every Steve Trucking arrow (chapter 7 module 7). Part 2 taught the mechanisms. This chapter puts them together.
Each Pattern, and What Carries It
Section titled “Each Pattern, and What Carries It”Here’s the map from the six patterns to the mechanisms you’ve now met, each with the chapter that teaches it.
The pattern narrows the choice. It doesn’t make it.
| Pattern | Mechanisms that carry it | Where the course teaches them |
|---|---|---|
| Request and Reply | A callout from Apex or a flow; External Services | Chapter 9, where a callout can run |
| Fire and Forget | A platform event; a callout handed off to a background job; an outbound message | Chapter 11; chapter 9 |
| Batch Data Synchronization | The Bulk API; Change Data Capture, with a batch underneath | Chapter 10, keeping a copy in sync; chapter 11 |
| Remote Call-In | The REST and Composite APIs; your own Apex REST door; the Bulk API for volume | Chapter 8; chapter 10 |
| UI Update Based on Data Changes | Platform events or Change Data Capture, with the page subscribed | Chapter 11 |
| Data Virtualization | Salesforce Connect; a component that calls out, shows the data and keeps nothing | Chapter 19 (coming soon); chapter 9 |
Two things to notice. First, every row has more than one answer. Second, the same mechanism turns up in more than one row: a platform event can be fire and forget or a screen update, and the Bulk API can be a nightly copy or a partner loading a file. A mechanism doesn’t tell you the pattern, and a pattern doesn’t tell you the mechanism. You need both, in that order.
One Arrow, Three Ways to Build It
Section titled “One Arrow, Three Ways to Build It”Take one Steve Trucking arrow. The day before a delivery, Salesforce asks the SMS and email provider to send the recipient a message. Checkpoint 1 called it a fire and forget: Salesforce asks, gets an acknowledgment, and moves on. The pattern was settled in Part 1. The mechanism wasn’t.
Same pattern, three mechanisms.
A callout from Salesforce. A background job, or a flow’s asynchronous path, calls the provider’s API directly (chapter 9 module 5). Nothing else in the landscape is involved. But Salesforce now holds the provider’s credential, the retries and the log, and the Salesforce team owns all three (chapter 14).
A platform event to the integration layer. Salesforce publishes “a message is due” and moves on (chapter 11). The integration layer, which already takes Steve Trucking’s status events, calls the provider and owns the retries. Salesforce stays simple; the layer team has one more flow to run.
An outbound message. Built with clicks, queued and retried by Salesforce for up to 24 hours (chapter 9 module 7). But it sends Salesforce’s own SOAP message and waits for Salesforce’s own acknowledgment back. The provider’s API doesn’t speak that, so something in between has to turn it into the right call. And Salesforce says it will keep outbound messaging going “within current functional capacities, but does not plan on making further investments in this technology” (Data Integration with Salesforce (opens in a new tab), checked 2026-11-07).
All three are fire and forget. All three would work. So what decides? Not the pattern. Things the pattern doesn’t know:
- Who builds it and runs it, and what that team is good at.
- The numbers: how many messages, at the busiest hour, and what each one counts against.
- What’s already there: a layer that already takes the status events is a door that’s already open.
- What it costs, in licences, in allocations and in people.
Those are this chapter’s next modules: what Salesforce’s own guide says (module 2), the forces (module 3), and how to weigh them (module 4). Checkpoint 2 makes the pick for this arrow, with the numbers (module 7).
Test knowledge. Separate the pattern from the mechanism. Expect a scenario that describes the requirements and asks for the Salesforce mechanism. Name the pattern first; then choose among the mechanisms that carry it, using the details the scenario gives (who maintains it, the volume, what’s already in the landscape).
Beyond the exam: what AI changes. Ask an AI assistant how to send a message from Salesforce, and it will usually answer with a mechanism, and often a good one. What it can’t know is which team will run it, what’s already in your landscape, or what you pay for. Ask it the pattern question first, then give it those facts, and its answer gets much better. Better still, ask it for three mechanisms and what each one costs you.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- For every arrow: the pattern first, in words that name no product.
- The mechanisms that could carry it, more than one, from the doors Salesforce has.
- What the pattern doesn’t know: who runs it, the numbers, what’s already there, what it costs.
- Which mechanism, and why, said so someone else could check the reasons.
Explore
Section titled “Explore”- Requirements, Then Pattern, Then Mechanism: the order, in the Data Architect course.
- Choosing a Pattern: chapter 7, the three questions and Salesforce’s selection tables.
- Salesforce Architects, Data Integration with Salesforce (opens in a new tab) (checked 2026-11-07).