Trade-offs, the Course's Way

Module 4 of 7 in the chapter Choosing the Right Integration Design, chapter 16 of the Integration Architect course. Each module stands on its own. Previous: The Forces · Next: Combining Mechanisms, and Licensing Them

The question this module answers: When the requirement doesn’t settle it, how do you choose between two designs that both work, and how do you explain the choice?

Choose Between Imperfect Options

Module 3 ended with a promise. Most of the time, when two forces pull against each other, the requirement settles it. When it doesn’t, you have a real trade-off.

I put it on a slide this way: trade-offs mean you choose between imperfect options. There’s rarely a design with no cost. There are many ways to solve a problem. Some are wrong the moment you look at them. Some work today and go bad in a year. A few are viable, and choosing among those few is the architect’s job.

Trade-offs are different in every domain, so each course teaches its own, with its own examples. The method is the same everywhere. Here it is, with integrations.

A Balanced Solution

When I teach the CTA exam, I sort the parts of a solution into three kinds. I call it a balanced solution.

Click to enlarge

Judge the whole, not each part.

Optimal: a tool used for its core strengths. A nightly set of records through the Bulk API (chapter 10). An event for news several systems want (chapter 11).

Sub-optimal, on purpose: one part gives something up, so the whole solution stays healthy. Steve Trucking’s truck positions are up to a minute old (module 3). On their own, fresher would be better. But one call per reading would spend 200,000 calls a day of the org’s API allocation, and every other integration shares that allocation. So the positions are a little older, on purpose, and the whole org stays healthy. The skill is saying so out loud, before someone finds it and calls it a bug.

Non-functional, or short-term functional: it seems to work, and it has a weakness that shows up later. That’s the dangerous one, because it passes the demo.

What Goes Bad in a Year

On Salesforce, what goes bad in a year is usually volume. Here’s one I lived through.

Records came in through an integration, and for each one, the code ran a query to find the related records it belonged with. In testing, with a handful of records, it was fine. Then real traffic arrived: thousands of records in ten or twenty minutes. Every one ran its own query, and the query wasn’t selective. Thousands of unnecessary queries, and a system that slowed to a crawl.

The fix changed the design, not the code. We removed the query. The records came in first, and a periodic batch process built the relationships afterwards. As I said at the time, the programmers didn’t anticipate the volume, and then they needed to redesign the system with it in mind.

Two lessons, and they’re both this course’s. Count the zeros, three years out (chapter 6 module 3). And test at real volume before go-live, because a design that’s short-term functional looks exactly like an optimal one until the traffic comes.

Present Both, Then Say What You Think

Sooner or later, someone asks: why not the other option? Here’s how I answer.

You need to be able to present the technical approach for both options: the one you’re choosing and the one you’re not. Technical details for each, and the pros and cons of each, laid out fairly. Only then do you give your recommendation, and I close it with a deliberate phrase: “In my professional opinion, I believe that option A is the best option.”

That phrase does two jobs. It shows the choice was weighed, because the other option was set out fairly first. And it shows confidence. You’re the architect; you own the call. Sometimes your professional opinion is the best way to convey your confidence in a decision.

The Trade-off Card

To make that a habit, I write each real trade-off on one card:

1. The decision, in one line.
2. Both options, each with its technical approach, its pros and its cons.
3. The forces each one costs (module 3).
4. The time test: does it work now, at scale, and in a year?
5. The choice, in my professional opinion.
6. One breath: the requirement, the solution and the reason, said together.

Here’s one, filled in for the arrow module 1 left open: Steve Trucking’s day-before message, a fire and forget, which could be a callout from Salesforce or a platform event to the integration layer.

Click to enlarge

Both options, fairly, then the call.

Option A, a callout from Salesforce. Nothing else in the landscape is involved, and there’s one place to look when it fails. But Salesforce holds the provider’s credential, its retries and its log, and the Salesforce team runs them (chapter 14).

Option B, a platform event to the integration layer. Salesforce publishes and moves on. The layer, which already takes Steve Trucking’s status events, calls the provider and owns the retries. The cost is one more flow for the layer team, and a second hop to look through when something goes wrong.

The time test. Both work now. At scale, and in a year, when the provider changes its API or Steve Trucking adds a second provider, option B keeps that change out of Salesforce.

In my professional opinion, option B is the better choice.

In one breath: the recipient must get the message the day before, so Salesforce publishes an event and the integration layer, which already sends Steve Trucking’s other outbound news, sends it, because that keeps every outside call and its retries in one place.

That last line is the one that matters most. If you can’t say the requirement, the solution and the reason together, you haven’t finished deciding.

Test knowledge. The exam asks you to choose the best design and justify it. Expect two answers that would both work. Pick the one that meets the requirement with the fewest costs on the forces the scenario mentions, and be able to say why the other one is second.

Beyond the exam: what AI changes. At TDX 2026 I put it this way: “Speed increases, but trade-offs do not disappear. Good design is not just what works. It is what still works at scale, under stress, and over time.” An AI assistant can draft both options and their pros and cons in seconds, and that’s a real help: it fills in the card. What it can’t do is own the call. The professional opinion is yours, and so is the one breath that explains it.

What an Architect Decides Here

• Which decisions are real trade-offs, after the requirement has settled what it can.
• For each: both options, fairly, with their technical approach, pros and cons.
• Which parts are sub-optimal on purpose, and saying so before anyone else finds them.
• The choice, as your professional opinion, and the one breath that explains it.

Explore

• The Forces: module 3, what each option costs.
• Steve’s Number of Zeros: chapter 6, the volume that turns a design short-term functional.