A team replaces a tangle of event listeners with a single orchestrator service that explicitly calls each participant of an onboarding workflow. Why do critics call the orchestrator 'the new coupling point,' and what operational cost does that concentration create?

## How orchestration inverts the dependency direction Orchestration works by inverting choreography's dependency direction: instead of many services each independently depending on an event schema, one service — the orchestrator — depends directly on every participant's command interface, and holds the full sequence of steps as explicit code or configuration (a state machine, a workflow-engine definition, or a BPMN process). Concretely, adding a new step to the process — say, a fraud check between "account created" and "welcome email sent" — means editing the orchestrator's process definition and redeploying it, even though the fraud-check service itself is a completely independent team's code. ## Why critics call it the new coupling point This concentration is exactly the point of orchestration: it buys a single place to see and reason about the whole process. But that same concentration is what critics mean by "the new coupling point." | Style | Shape of the coupling | |---|---| | Choreography | coupling is diffuse — many services loosely coupled to a shared event schema, discoverable only reactively (as in the schema-coupling problem) | | Orchestration | coupling is dense but explicit — a smaller number of very direct, very visible dependencies, all radiating from one component | Density has real costs even though visibility improves. ## The three costs of concentration 1. **The first cost is availability.** Because the orchestrator holds the only record of "where each in-flight process instance currently stands," if it's down, degraded, or backed up, no workflow instance of that type can advance — even if every participant service is perfectly healthy. This makes the orchestrator's own uptime and scaling characteristics a hard ceiling on the whole process's throughput, unlike choreography where a slow or down consumer only stalls the specific downstream step it owns, and unrelated steps (a different consumer of the same event) keep working. 2. **The second cost is organizational.** In most real orgs, the orchestrator is owned by one team, but the steps it calls are owned by several others. Any change to step ordering, branching, or timeout policy requires a change in the orchestrator's codebase — meaning the owning team must review, prioritize, and ship it, even when the actual business need originates elsewhere (e.g., the fraud team wanting their check inserted earlier in the flow). This turns the orchestrator into a queue: a Conway's-Law-style bottleneck where cross-team workflow changes compete for one team's attention and deploy schedule, which is exactly the kind of centralized-change friction microservices were adopted to avoid in the first place. 3. **The third, more insidious cost is logic creep.** Because the orchestrator is the one place that "knows everything" about the process, it's tempting to put business rules there too — conditional branching that really encodes domain policy ("skip KYC for low-risk customers under $500") rather than pure sequencing. Once that happens, the orchestrator stops being a thin coordination layer and starts being a shadow domain service that duplicates or shadows logic that should live in the participant that owns that domain concept. Teams describe the end state as a "distributed monolith": you still pay all the deployment, network, and operational overhead of many services, but you've recreated a single codebase's tight coupling and single point of change inside the orchestrator. ## What to do about it The standard mitigations are: - keep the orchestrator intentionally thin (pure sequencing/timeouts/retries, no domain rules); - give each participant ownership of its own business decisions (the orchestrator asks "should we skip KYC for this customer?" via a call to the risk service rather than encoding that rule itself); - invest in the orchestrator's own high availability and horizontal scaling as first-class infrastructure; - and, at an org level, treat changes to the process definition as a lightweight, self-service change (e.g. a declarative workflow config any team can PR) rather than a bespoke code change gatekept by one team. Workflow engines like Temporal, AWS Step Functions, and Camunda are widely used precisely because they externalize the sequencing logic into a reviewable, versionable definition and provide built-in durability and scaling, reducing (though not eliminating) the availability and ownership costs described above.