Concepts
Orchestration vs. choreography
Intuition
Imagine organizing a dinner at home with several guests helping with the preparation. One way is for you, as host, to give the instructions: "now chop the salad", "now turn on the oven" — a central conductor who knows the whole recipe and tells each person what to do and when. The other way is to agree beforehand that each person reacts to what the previous one finishes: whoever chops the salad announces "done" and whoever handles the oven starts on hearing that, with nobody giving orders — each one only pays attention to the others' announcements. Both ways produce the same finished dinner, but they are organized in very different ways.
How it works
When the saga pattern is applied in microservice architectures, the "steps" stop being subtransactions of a single database and become calls to independent services, each with its own storage — and, since there is no longer a single transaction manager able to coordinate a distributed commit among them, someone has to explicitly decide the order of the steps and trigger the compensations when something fails. In orchestration, a central coordinator knows the entire saga flow and triggers each step in sequence, calling each service directly and, if a step fails, invoking the compensations of the steps already completed in reverse order — the coordinator concentrates visibility into the state of the process, but it also concentrates coupling: it needs to know about all the services involved. In choreography, there is no such coordinator: each service executes its step and emits an event announcing what happened, and the next service reacts to that event to execute its own step (including, if necessary, reacting to a failure event by executing its own compensation) — coordination emerges from the sum of the individual reactions, with no single component knowing the entire flow. In both cases, what is preserved is the original guarantee of the saga concept: the process as a whole observably ends up either fully completed or fully undone, even without full isolation during its execution — only where the knowledge about the sequence of steps lives and who triggers the compensations changes.
In practice
Orchestration tends to be preferred when the business flow is complex or changes frequently, because having the entire logic in one place makes the process easier to understand, debug, and change, at the cost of an orchestrator service coupled to all the others. Choreography tends to be preferred when you want to keep services more decoupled from each other and the flow is relatively stable, at the cost of making it harder to see "the state of the saga" as a whole, since it is implicitly spread across each service's event handlers.
Use it in a design
Practice the cases that rely on this concept in the System Design school.