Orchestration versus choreography: the first fork

Where must the global picture of a pipeline live, and what does choreography really buy?

Before any question about graphs, there is a prior question: does global state exist anywhere?

Orchestration puts one component in possession of the whole plan. It knows every step, every dependency and the status of each. An example is a central scheduler with a stored definition: "extract, then clean, then load, then refresh."

Choreography has no such component. Each stage emits an event on completion, and each downstream stage subscribes and reacts. (An event is a small message: "order export finished for 5 March.") The pipeline exists only as an emergent property of who happens to be listening. This is Marigold's current chain of watchers.

Why the global picture must live somewhere

The argument is short and strict. Someone must be able to answer: "Is this pipeline done, and if not, where is it?"

In orchestration, the answer is a row lookup in the orchestrator's database.
In choreography, no single participant has enough information to answer. The answer must be reconstructed by correlating events across systems with a trace ID (an identifier attached to every event of one logical run, so events can be joined afterwards). That correlated record is exactly the information the orchestrator was storing for free.

Costs are conserved. Choreography does not remove global state. It relocates it from the control plane into the observability plane, where it is reconstructed after the fact and only approximately.

What choreography does buy

Choreography removes a coupling point. In orchestration, adding a step means editing the central definition. Someone owns that definition, which means a pull request against another team's repository. In choreography, adding a consumer requires no change to the producer at all. This is a real and large organizational win. It is why event-driven pipelines dominate across team boundaries while explicit DAGs dominate within a team.

The trade is "coupling versus coordination cost". It resolves differently depending on whether the boundary is technical or organizational.

The position nearly everyone reaches: orchestrated islands, choreographed between them. This is not a compromise. It is a recognition that the cost being minimized differs on each side of an ownership line.

Choreography deletes the coordinator, not the coordination; the global view moves to the tracing system and gets worse.

Case, resolvedConstructed case · Tomás at Marigold Market

Is Saturday's run finished? Nobody knows

Nadia asked whether Saturday's pipeline had finished and, if not, where it was stuck, and nobody could say: the chain of cron watchers had no global picture. Where it started: A layer that moves nothing →

The chain of watchers was choreography with no trace ID. The global view had to be rebuilt by hand from four logs, which is why it took forty minutes. Tomás decides to orchestrate inside his own team: one workflow definition for "extract, clean, load, refresh", with a run record per day. The question "where is Saturday's pipeline?" becomes one row lookup. Between his team and the refund team he keeps events, because the refund team should not need his approval to add a consumer.

He also learns the second lesson of this article. That empty-file step returned exit code 0 because it believed it had worked: the orchestrator only receives claims, so the run record now checks the output (a row count above zero) before it says "finished".