Steve Trucking Under Load

Module 7 of 7 in the chapter Choosing the Right Integration Design, chapter 16 of the Integration Architect course, and the end of Part 2. Previous: Write the Design Down · Next: Part 3 begins with The Story of Integration (coming soon)

The question this module answers: For Steve Trucking, how is every integration built, and does the whole design hold up under its numbers, today and in three years?

Try it first. Take Checkpoint 1’s table, every arrow with its pattern. For each one, write down the mechanism, the identity it signs in as, what happens when it fails, and what it counts against. Then add up the event deliveries for the whole org, and compare them with the allocation. Then read on, and compare your reasons, not just your answers.

Where Part 1 Left Off

Checkpoint 1 ended with every Steve Trucking arrow and its pattern, and a promise: “Not one pattern changes. What changes is the mechanism underneath and its limits, and that’s Part 2.” Part 2 is done. Here’s the same company, with the same numbers: about 3,300 deliveries a day, eight status updates each, 13,200 photos, growing 30% a year.

The order is this chapter’s: pattern first, then the mechanism (module 1); the forces that choose it (module 3); and every decision written down so someone else can check it (module 6).

Every Arrow, Its Mechanism

Click to enlarge

Same patterns as Part 1. Now every arrow has a mechanism, and a plan for when it fails.

Here’s each one, with its reasons.

Redrock’s manifests in. Remote Call-In. Each evening, one set per distribution center, about 370 deliveries, then single revisions during the day. A Composite call carries up to five sets of 200, upserted by Redrock’s reference as the External ID, so 370 is one call, and Redrock gets an answer for every delivery right away (chapter 8 module 3, chapter 10 module 7). The integration layer signs in as the manifests user, which creates and updates Work Orders by the partner key and nothing else (chapter 13 module 4). If a call fails, Redrock resends, and because its reference is our key, a resend updates instead of duplicating (chapter 14 module 1).

Keystone’s and Brightwave’s manifests in. Batch Data Synchronization. Their files arrive each afternoon; the layer loads each one through the Bulk API, and counts what went in against what came out before it calls the file done (chapter 10 module 6).

FleetLink’s latest position. Remote Call-In, one call a minute (module 3). 330 trucks is more than one set of 200, so the call is a Composite request with two sets, upserted by truck: 720 calls over a twelve-hour day instead of 200,000. FleetLink signs in as its own user, which can update a truck’s last position and nothing else. If its credentials leak, the thief can move a truck on a map; they can’t read a single delivery. And its failure plan is different from the others: a missed minute doesn’t need a retry, because the next minute replaces it. What needs an alert is silence. If no position arrives for, say, ten minutes during delivery hours, someone is told (chapter 14 module 6).

Status changes out. Fire and Forget, published as events. Change Data Capture on the Work Order, through a filtered channel that passes only status changes, with the integration layer as the only outside subscriber, signed in as its own status-events user (chapter 11 module 3). The layer passes each change on: to Redrock by webhook as it happens, to Brightwave as EDI messages, and to Snowflake’s status history. If the layer is down, it replays from where it stopped, inside the 72 hours the bus keeps them (chapter 11 module 4). And underneath, the batch: a weekly bulk export to Snowflake, about 23,000 deliveries, to catch anything the events missed (chapter 10).

Keystone’s status file. Keystone wants one file a night, not a call per change. The layer builds it from a bulk query of the day’s status changes, about 8,800 rows, and keeps Keystone’s pickup as the return receipt (chapter 14 module 5).

Delivery counts to finance. Batch Data Synchronization. Once a day, the layer queries the day’s completed deliveries per partner and sends one set to the finance ERP, which invoices monthly. A day’s counts replace that day’s counts, so a failed run is simply run again. If Steve Trucking ever sells paid redeliveries, that’s a saga with an undo step for every charge, and chapter 15 drew it (chapter 15 module 5).

Photos. Fire and Forget, sized by their bytes: about 13,200 a day, about 53 GB. Checkpoint 1 left this one for Part 2, and the answer is that the bytes never go through Salesforce at all. The crew’s app uploads each photo straight to photo storage, retrying when the signal comes back. Salesforce talks to the storage only with a signed request through a named credential (chapter 13 module 6), and the org keeps only what it needs: a count, and a “required install photos complete” flag (the Data Architect course’s Checkpoint 1). No API calls, no file storage, no event deliveries. The cost lands on the storage bill instead.

The day-before message. Fire and Forget: a platform event, “a message is due,” to the integration layer, which calls the SMS and email provider and retries with the same key. That was option B, and module 6 wrote down its record (module 4, module 6).

On the coordinators’ screens. UI Update Based on Data Changes: a manifest changes after routing, or a truck is likely to miss its window. The obvious mechanism is a page component listening to events, and it’s the expensive one. Salesforce counts every delivery “to Pub/Sub API and CometD subscribers, empApi Lightning components, and event relays” (Change Data Capture Allocations (opens in a new tab), checked 2026-11-07), so 45 coordinators each listening would multiply the count. Instead, a record-triggered flow reacts to the change in the record itself, the manifest or the truck’s new position, and sends the coordinator a notification. No event is delivered to anyone outside the org, so nothing is counted. Even where a design does use events inside the org, deliveries to flows and triggers “don’t count against the delivery allocation” (chapter 11 module 6).

The Meter

Now add it up. Chapter 11 found Steve Trucking over its event allocation on day one, on Enterprise Edition, the same “what if” as chapter 6 (chapter 11 module 5). Change events and platform events draw from the same meter: “The event delivery allocation is shared between high-volume platform events and Change Data Capture events” (checked 2026-11-07). So the day-before messages count too.

Click to enlarge

The status changes alone are over the line. Plan the add-on from day one.

Today: 26,400 status changes plus 3,300 day-before messages, each delivered once, to the layer: about 29,700 a day, against 25,000.

Year three: about 58,000 plus about 7,300: about 65,300 a day. That’s over Unlimited Edition’s default of 50,000 too, so changing edition alone doesn’t fix it.

With an add-on: the platform event add-on “increases the 24-hour allocation of delivered event messages by 100,000 per day” (chapter 11). On Enterprise, that’s 125,000, and year three fits with room. Change Data Capture has its own add-on, and the meter is shared, so which one fits a mix of both is a question for the Salesforce account team, with the numbers in hand.

Notice what that does to module 4’s choice. The status changes alone are over the line, so the add-on is needed whichever way the day-before message is built. With it, the messages fit. So the numbers don’t reopen the decision; they confirm it, and they put a line in the running cost that has to be in the budget from day one.

The API allocation is the easy one. In chapter 6’s “what if,” the org has 300,000 calls in 24 hours. FleetLink’s 720, a few Composite calls each evening and one per revision, a few dozen bulk calls a night: a few thousand at most. The design that would have spent it, one call per truck reading, is the one module 3 set aside.

Three Years Out

At 30% a year, year three is about 2.2 times today. Count again, and change the door only where the count crosses a line (chapter 10 module 7):

• Redrock’s sets grow to about 810. Still one Composite call. If Redrock ever sends one set for all three centers, about 2,400, the layer moves it to the Bulk API every 30 minutes, and Redrock hears about each delivery within the half hour instead of straight away. That’s the trade to agree with Redrock before switching.
• FleetLink: if the fleet grows with the deliveries, about 730 trucks. Still one Composite call a minute.
• Events: about 65,300 deliveries a day, inside the add-on.
• Photos: about 116 GB a day, still never through Salesforce. The storage grows; the org doesn’t.
• Keystone’s file, the weekly export, finance’s counts: bigger, and still far inside the loading dock’s limits.

Not one mechanism changes because of growth, except one that only changes if a partner changes how it sends. That’s what a design that “still works at scale” looks like.

What I’d Still Check

Part 2 gave every arrow a mechanism and a plan. These are the questions it leaves for the first weeks of the project:

• The provider’s repeat key: does the SMS and email provider recognize a repeat, so a retry never sends two texts? (module 6)
• The add-on: which one, at what terms, for a mix of change events and platform events, with the account team.
• Redrock’s sets: will they stay one per center? If not, agree the half hour before the switch.
• FleetLink’s silence: how many quiet minutes during delivery hours mean something’s wrong, and who’s told.
• Every record written down, as module 6 did for the day-before message: one per arrow.

Test knowledge. This is the shape of a design question on the exam: a landscape, the numbers, and a set of requirements. For each integration, be ready to name the pattern, the mechanism and why, how it authenticates, how it handles failure, and what limit it’s closest to. Do the arithmetic for event deliveries and API calls across the whole org, not one integration at a time.

Beyond the exam: what AI changes. Give an AI assistant this landscape and these numbers, and it will propose a mechanism for every arrow in a minute. Some of them will be good. Then ask it to add up the event deliveries for the whole org, and to tell you which deliveries don’t count. That’s where you’ll find out whether it knows the meter, or just the mechanisms. The design is only finished when the sum is done, and someone has checked it.

What an Architect Decides Here

• For every arrow: the mechanism, and the reason, written in its record.
• The identity, the failure plan and the running cost of each one.
• The sums for the whole org: event deliveries, API calls, storage, today and at year three.
• What the sums require: an add-on, an edition, a change of door, and when.
• What’s still to confirm, and who confirms it.

Explore

• Checkpoint 1: Steve Trucking, What I Would Architect: where these patterns came from.
• Change Data Capture Developer Guide, Change Data Capture Allocations (opens in a new tab) (checked 2026-11-07).
• Allocations: chapter 11, the event meter in full.
• The Story of Integration (coming soon): Part 3 begins.