Steve Trucking, What I Would Architect

Module 7 of 7 in the chapter Integration Patterns, chapter 7 of the Integration Architect course, and the end of Part 1. Previous: Several Patterns, One Solution · Next: Part 2 begins with Salesforce as an API Provider (coming soon)

Try the challenge first. This is my walkthrough of Checkpoint 1’s challenge. If you haven’t drawn your own landscape, sized it and named a pattern for every arrow, do that before you read on. Then compare your reasoning, not just your answers.

The question this module answers: For Steve Trucking, what does every integration need to move, how much, and which pattern does each one use?

This is the end of Part 1. You can draw a landscape, ask for the requirements, do the math, and name the patterns. So let’s do all four, on one company, the way I’d do it in the first weeks of a project.

Start With the Landscape

Here’s Steve Trucking, the way you drew it in chapter 5: people on the left, the org in the middle, the integration layer just to its right, the systems on the right, partners and providers at the bottom right. Every arrow starts at the system that opens the connection.

Click to enlarge

Steve Trucking’s landscape.

The arrows from people to Salesforce, logging in, aren’t integrations. Everything else is, and every one of them needs a pattern.

Then the Numbers

Do your math early. These are the numbers from chapter 6, today:

• Deliveries: about 3,300 a day, growing 30% a year.
• Status updates: about eight per delivery, so about 26,400 a day. Over a twelve-hour day, that’s under one a second.
• Photos: about 13,200 a day at about 4 MB each: about 53 GB a day, about 1.2 MB a second. Few calls, heavy bytes.
• GPS readings: about 200,000 a day from FleetLink.

None of these is big for Salesforce. But two of them have a shape that matters. The photos are all bytes. And FleetLink’s readings, one call each, would spend most of the org’s daily allocation of inbound calls, as you saw in chapter 6.

Every Arrow, Its Pattern

Now the three questions from module 5 for every arrow: which way, what kind, does anyone wait. Then the numbers.

Click to enlarge

Every arrow, its pattern.

Here’s my reasoning, arrow by arrow.

The manifests coming in are two patterns, not one. On the landscape it’s one arrow, the integration layer upserting manifests with the partner key. But Redrock sends its manifests through its API as they come, and the layer passes each one on: Remote Call-In, with our own middleware as the caller. Keystone drops a file each afternoon and Brightwave’s come as EDI files: the layer loads each file in bulk, and nobody is waiting: Batch Data Synchronization. One arrow on the landscape, two patterns, because the partners behave differently. That’s why you ask the shape of every flow behind an arrow.

FleetLink’s latest position is Remote Call-In. It’s data, FleetLink starts it, and each call waits for Salesforce’s answer. The pattern was never the question. The numbers were: one call per reading is 200,000 calls a day. But coordinators must be alerted within five minutes when a truck is likely to miss its window, so they need positions within a minute or two, not within seconds. One call a minute with every truck’s latest position is 720 calls over a twelve-hour day. Same pattern, two very different designs.

The status events are a fire and forget, published as events. A delivery’s status changes, and several systems care: the integration layer for the partners, the status history in Snowflake. Nobody waits for them. So Salesforce publishes once and moves on, and the subscribers take their copy in their own time, module 4. And remember: you get a receipt, not the outcome.

The delivery counts to Finance are a batch. The requirement is to invoice each partner daily from completed deliveries. Finance doesn’t need each delivery the second it’s done; it needs the whole day, complete, by morning. Batch Data Synchronization, going out. The selection tables list batch only coming in, but it works in either direction.

The photos are a fire and forget, sized by their bytes. The crew doesn’t wait for storage to confirm each photo. But 53 GB a day is the number that will decide the mechanism, not the pattern. That’s for Part 2.

The day-before message is a fire and forget. Salesforce asks the provider to send it, gets an acknowledgment, and moves on. Whether the text reached the phone is the provider’s job, and its report.

Two requirements live on the screen. When a manifest changes after routing, coordinators must see it immediately, and they must be alerted within five minutes when a truck is likely to miss its window. Both are UI Update Based on Data Changes: the coordinator’s screen is told, it doesn’t keep asking, module 3.

The partner side has patterns too, just not Salesforce’s names. Status goes back to each partner the way it wants it: Redrock by webhook as it happens, Keystone as a file each night, Brightwave as EDI messages. Those arrows don’t touch Salesforce, so Salesforce’s six don’t name them. The industry’s names do: a call for each event, a file, a message through a third party.

One more requirement doesn’t have an arrow yet: RouteDesk’s eight years of history must stay available after it retires. Whether that’s a migration, an archive, or data virtualization is a design of its own, and the Data Architect course and chapter 14 take it on.

Where I’d Layer a Batch

Batch is your backup plan. So here’s where I’d put one underneath.

The status history in Snowflake gets every status change through events, and a nightly batch reads the day’s changes by date and fills any gap, the design from module 5. The same idea protects Redrock’s webhooks: a nightly comparison of what we sent and what Redrock has. And Keystone already gets a nightly file, so its status is a batch from the start.

Three Years Out

The brief asks for three times today’s volume within five years, and chapter 6 planned 30% a year. In three years, that’s about 2.2 times today: about 58,000 status updates a day, and about 116 GB of photos a day.

Look at the table again. Not one pattern changes. The status events are still a fire and forget, the counts are still a batch, FleetLink still calls in. What changes is the mechanism underneath and its limits, and that’s Part 2.

What’s Still Open

Part 1 gave each arrow its pattern. Part 2 picks how to build each one, and checks it against its limits:

• Salesforce as the provider, for the call-ins: chapter 8.
• Salesforce as the client, for the call-outs: chapter 9.
• Bulk, for the batches and the photos: chapter 10.
• Events, for the status changes and the screens: chapter 11.
• And how every caller signs in: chapter 12.

What an Architect Decides Here

• For every arrow on the landscape: its pattern, from which way, what kind and whether anyone waits.
• For every arrow that hides several flows: a pattern for each flow, not one for the arrow.
• For every pattern: the numbers that will decide its mechanism, today and in three years.
• For every event-driven flow: the batch underneath.

Beyond the exam: what AI changes. Put this landscape and the brief into an AI and ask for a pattern per arrow, and you’ll get a table much like this one. What it won’t do on its own is notice that one arrow is two patterns, ask whether coordinators need seconds or minutes, or count FleetLink’s calls against the allocation. Give it the three questions and the numbers, and check every row the way you just did.

Explore

• The Steve Trucking brief: the requirements R1 to R15 and the volumes behind this checkpoint.
• Salesforce Architects, Integration Patterns (opens in a new tab): the selection tables, checked 2026-11-01.