A platform team wants the loose coupling of choreography for straightforward event fan-out, but the auditability and explicit control of orchestration for the parts of a process with strict ordering, SLAs, and branching. What hybrid approach lets them get both within the same business process, and what new problem does the hybrid itself introduce?

## Orchestrated core, choreographed edges The hybrid pattern is usually described as an "orchestrated core, choreographed edges" design. Mechanically, it looks like this: - The business-critical steps of a process — the ones with real ordering constraints, cross-step timeouts, conditional branching, and a genuine need for a single queryable "where does instance 123 currently stand" — are driven by an explicit orchestrator or workflow engine, exactly as described for a control-flow-heavy flow. - That orchestrator, however, doesn't try to also own every side effect the business cares about. Instead, at meaningful state transitions (order shipped, application approved, account activated) it publishes an ordinary domain event onto the broker. - Any number of independent, order-insensitive consumers — marketing, analytics, a recommendations model, customer-support tooling — subscribe to that event choreography-style, exactly as they would to any other event, with zero awareness that an orchestrator produced it and zero ability to affect the orchestrator's own sequencing. ## The tension it resolves This exists to resolve a real tension: | Pure style | Where it breaks down | |---|---| | Pure orchestration | forces every consumer, however trivial, to be a participant the orchestrator explicitly knows about and calls, which means adding a "send a marketing email on shipment" feature requires touching the orchestrator's code and redeploying a component that other, more critical steps depend on for availability | | Pure choreography | on the other hand, struggles once the core steps need explicit branching, timeouts, and audit-grade state tracking, as covered by the control-flow-complexity signal | The hybrid resolves both: the orchestrator stays thin and focused purely on the steps that actually need centralized control, while everything else attaches to its output via ordinary, decoupled subscription, exactly as if the orchestrator were just another well-behaved event producer. ## What it costs to run The trade-off is real but favorable when the boundary is well drawn: teams get orchestration's visibility and control exactly where it earns its cost (the critical path) and choreography's low-friction extensibility exactly where it earns its cost (peripheral, independent reactions), without paying either style's downside where it doesn't apply. The operational cost is that the team now runs and monitors two different coordination surfaces — a workflow-engine dashboard tracking orchestrator instance state, and separate broker/consumer-lag/dead-letter-queue monitoring for the choreographed edges — rather than one unified picture. ## Boundary drift, the hybrid's own new problem The new problem the hybrid itself introduces is **boundary drift**, sometimes called scope creep across the seam. Nothing enforces, at a technical level, that a "peripheral" choreographed consumer stays genuinely independent and non-load-bearing. - In practice, a consumer that started as a nice-to-have (say, a loyalty-points service reacting to `OrderShipped`) can quietly become something the business actually depends on for correctness or compliance, without anyone updating its classification — so when it silently fails, the team mistakes it for a cosmetic, non-critical failure (because that's how it's labeled and monitored) when it has actually broken a real downstream business guarantee. - Symmetrically, pressure can build to pull more logic into the orchestrator "since it's already the source of truth," re-growing the logic-creep and single-point-of-failure risks that motivated keeping it thin in the first place. Because there are now two different mental models active in one process — "this is a command the orchestrator issued and tracks" versus "this is a fact anyone may have subscribed to without our knowledge" — engineers reasoning about a given step have to first figure out which model applies before they can reason about coupling, failure modes, or who to page, which is itself a cognitive cost the pure styles don't impose. ## Governing the seam The standard governance response is to make the boundary an explicit, written, and ideally lint-or-review-enforced convention rather than a tribal-knowledge one: a clear rule for what qualifies as - **core** (belongs inside the orchestrator's direct command calls: anything with hard ordering, SLA, or compliance requirements), - versus **edge** (choreographed: anything that's genuinely optional, independently retryable, and non-blocking for the business outcome), reviewed whenever a new consumer or a new orchestrator step is proposed. This is also, at heart, an org-design decision in the Conway's-Law sense: the orchestrator's boundary usually works best when it matches a single team's ownership boundary, so that the "who approves a change to the core workflow" question — and the associated bottleneck risk covered when discussing orchestration's coupling concentration — has one clear, accountable owner, while the choreographed edges remain genuinely open for any team to extend without needing that owner's sign-off at all. A widely recognizable real-world instance of this shape is an order-fulfillment critical path driven by a workflow engine (Temporal, AWS Step Functions, or a BPM engine are common choices) that emits domain events to a broker like Kafka, consumed independently by marketing, analytics, and support tooling teams who never interact with the workflow engine itself.