An order saga has three steps today (reserve inventory, charge the card, create the order) and product wants to add fraud review and a loyalty-points step, with a possible retry-then-escalate branch on fraud. Would you build this as choreography or orchestration, and why does that change as the saga grows?

Choreography — each service reacts to the previous step's event and publishes its own — works well for two or three steps that rarely change, because there's no extra component to run, just events. Its cost is that nobody owns the whole picture: the sequence lives as a set of listeners spread across every service's codebase, and 'why is this order stuck' means reading four codebases to reconstruct a flow that was never written down in one place. Orchestration puts that sequence in one component that calls each step and runs compensations on failure; the participants become simple ('do this, reply') and the one place the logic exists is the orchestrator. At three straight-line steps, choreography's simplicity wins. At five steps with a genuine branch — retry fraud review some number of times, then escalate to a human, otherwise continue — that's a state machine, and a state machine implicit across five services' listeners is one nobody actually drew; orchestration is where that branch belongs, explicitly, in one place.