Orchestration or Choreography

Module 4 of 8 in the chapter Integration Orchestration, chapter 15 of the Integration Architect course. Each module stands on its own. Previous: There’s No Rollback Across Systems · Next: The Saga and the Undo Step

The question this module answers: When several systems take part in one piece of work, should one of them direct the others, or should each react on its own?

Two Ways to Coordinate

There are two ways to get several systems working on one piece of business.

Orchestration has a conductor. One component knows the whole process: call accounting, then the ERP, then inventory, and what to do if any step fails. The others just do what they’re asked. Module 1’s middleware was a conductor.

Choreography has no conductor. Each system knows its own part and reacts to what it hears. Something happens, an event announces it, and whoever cares does their piece. Microsoft’s guide describes it as having “each service decide when and how to process a business operation, instead of depending on a central orchestrator.”

You’ve already met choreography in this course; it just wasn’t called that. When a flow publishes a platform event, Salesforce no longer needs the other system’s address, its credentials, or its retry logic. In my classes I put it this way: I’ve shifted the work onto the subscriber, and Salesforce becomes more passive, not active. Chapter 7 drew it as publish and subscribe, and chapter 11 built it (chapter 7 module 4; chapter 11 module 1). A publisher that doesn’t know who’s listening is choreography.

Click to enlarge

One place knows the whole story, or no place does.

What a Conductor Gives You, and Costs

The great advantage of a conductor is that somebody knows where the work is. Microsoft’s guide says the orchestrator “can consolidate the status of a transaction based on the results of individual operations.” Ask it about order 1042 and it can tell you: balance checked, ERP accepted, inventory failed, undo in progress. That’s module 3’s in-between status, kept in one place. And when a step fails, the conductor decides what happens, in one place, the same way every time.

The cost is that the conductor has to be right, and it has to be up. The same guide is blunt: “Under load, it can introduce performance bottlenecks and be the single point of failure (SPoF).” If the conductor is down, every process it conducts is down. And it knows every system’s part, so every change to any of them is a change to the conductor too.

What Choreography Gives You, and Costs

Choreography’s advantage is that nobody is in the middle. No single component knows everyone’s business, and none of them can stop the others. Add a system that wants to hear about new orders, and it simply starts listening. The publisher doesn’t change. Microsoft’s guide names this as a reason to choose it: when “You expect to frequently update and replace the components.”

The cost is the mirror image. Because “Each service completes their responsibility and isn’t aware of the overall workflow,” nobody knows the whole process. Where is order 1042? You have to ask every system and put the answers together. That’s why chapter 14’s one ID through every layer matters so much more here (chapter 14 module 2): with no conductor, the shared ID is the only way to follow one order.

And it gets harder when the order of the steps matters. The guide again: “This pattern suits a workflow that processes independent business operations in parallel. The workflow can become complicated when choreography needs to occur in a sequence.” If the ERP must not see the order until accounting has said yes, someone has to enforce that, and in choreography there’s no someone.

Failures are hard either way. As the guide warns, “Failure-handling logic, such as compensating transactions, is also prone to failures.” The conductor at least handles them in one place. In choreography, every system handles its own, and they have to agree.

Steve Trucking Uses Both

Look at Steve Trucking, and you’ll find both styles, which is normal.

Choreography: a delivery’s status changes, and Salesforce publishes an event. Salesforce doesn’t know who’s listening. In the integration layer, two separate subscribers hear it: one sends the status on toward the partners, the other sends it to Snowflake, which stores the history. Neither subscriber knows about the other. They’re independent and they run in parallel, exactly where the guide says choreography fits. A third subscriber next year changes nothing that’s already there.

Orchestration: the integration layer, once it has the status, conducts the delivery to each partner in that partner’s own way: Redrock’s webhook, Keystone’s nightly file, Brightwave’s EDI. It knows each partner’s format, retries, and receipts (chapter 14). That part has a sequence and a definite owner.

So the question isn’t “which style does our company use?” It’s which style each piece of work needs.

Choosing

Here’s how I’d choose, piece of work by piece of work:

Click to enlarge

Decide for each piece of work, not for the whole company.

The question underneath all five is the same one: who needs to know where the work is? If the business needs one answer, from one place, to “where is order 1042?”, you want a conductor. If each system only needs to do its own part when it hears the news, let them react.

Test knowledge. Know publish and subscribe as the choreography style: the publisher doesn’t know its subscribers, which keeps systems loosely coupled (Salesforce platform events and Change Data Capture). Know when a coordinating layer, such as middleware, is the better fit: a sequence of dependent steps, one place that knows each transaction’s status, and coordinated recovery when a step fails.

Beyond the exam: what AI changes. AI agents are pushing both styles further. A planning agent that calls tools one after another is a conductor; a set of agents each reacting to what the others post is choreography. The same trade-off applies: one knows the whole story and must be right, the other is flexible and hard to follow. Module 8 comes back to it.

What an Architect Decides Here

• For each piece of work that crosses systems: a conductor, or reactions, and why.
• Where the conductor’s status lives, so “where is this order?” has one answer.
• For choreography, the ID every system writes down, so one piece of work can still be followed.
• Who enforces the order of steps when the order matters.
• How failures are handled in each style, and by whom.

Explore

• Microsoft Learn, Azure Architecture Center, Choreography pattern (opens in a new tab) (checked 2026-11-07).
• Microsoft Learn, Azure Architecture Center, Saga design pattern (opens in a new tab): orchestration and choreography in a saga (checked 2026-11-07).
• Publish and Subscribe: chapter 7, the pattern behind choreography.