Fan-out / gather

All steps

Normal run

1. Request arrives. The dispatcher is plain code, not a model. Which checks run is decided at design time, not per request.
2. Fan out. The same case goes to three reviewers at once. Nothing is planned or decomposed; the split is always the same.
3. Reviewers work. Each reviewer answers one question in its own context. They share nothing and cannot wait on each other.
4. First results. Two reviewers finish. The aggregator holds their results and keeps waiting; the damage check is still calling the carrier.
5. Last result. The slowest branch reports. Only now is the barrier released, so the gather step is as slow as its slowest input.
6. Merge. Valid order 4417, damage confirmed, inside the 30-day window. The aggregator combines three verdicts into one decision.
7. Respond. Refund approved. Three checks took the time of one, at the token cost of all three.

Outcome: correct answer. Parallel branches traded tokens for latency. Unlike an orchestrator, nothing here was decided at run time, which makes the flow predictable and easy to test.

Failure mode

1. Request arrives. Identical start to the normal run.
2. Fan out. Three reviewers start in parallel, as before.
3. Reviewers work. Nothing has gone wrong yet.
4. Two results arrive. The order check and the policy check report on time. One branch is still open.
5. The straggler. The carrier's API is slow today and the damage check hangs on it. It has not failed, so it reports nothing at all.
6. The aggregator waits. Its rule is “wait for all three”. Two finished results sit unused, and there is no timeout and no partial-answer path.
7. The request times out. After thirty seconds the front end gives up and the customer sees an error. Two-thirds of the work was done and thrown away.

Failure: waiting on the straggler. A gather step is as slow as its slowest branch and, without a deadline, as slow as a hung one. Mitigation: per-branch timeouts, a rule for partial results, and cancelling branches that no longer matter.