Control flow · Established
Fan-out / Fan-in
Also known as: Scatter-gather, Map-reduce style parallelism, Parallel map
Fan-out / fan-in splits work into independent parts that run in parallel, then waits at a join point to collect and combine their results before the workflow continues.
01Problem it solves
Processing many independent items or queries one after another is slow, while unmanaged parallelism loses track of which parts finished, failed or still need to be merged.
02Use when / Avoid when
Use when
- Work splits into independent units (per file, per customer, per sub-query).
- Total latency matters more than the extra concurrent resource use.
- Results must be combined into one output after all or enough parts finish.
Avoid when
- Parts depend on each other's output; model the dependencies as a DAG.
- Downstream systems cannot take the burst of parallel calls.
- The number of parts is unbounded and you have no concurrency limit.
03How it works
- 1SplitThe input is divided into N independent work items.
- 2Fan outEach item is dispatched to a worker, up to a concurrency limit.
- 3TrackThe coordinator records completion and failure per item.
- 4Fan inAt the join, results are aggregated once all items, a quorum or a timeout is reached.
04Capabilities
| Capability | What it means |
|---|---|
| Parallel execution | Independent units of work run concurrently instead of one after another. |
| Result aggregation | Outputs from concurrent branches are collected and merged at a defined join point. |
05Tradeoffs
| Aspect | You gain | You pay |
|---|---|---|
| Speed | Wall-clock time approaches the slowest part instead of the sum. | Peak load on workers and dependencies rises sharply. |
| Failure handling | Parts fail and retry independently. | You must decide what a partial result means. |
06Failure considerations
| Failure mode | Mitigation |
|---|---|
| One slow part (straggler) holds the join indefinitely. | Set per-part timeouts and a join policy (all, quorum, best-effort). |
| Unbounded fan-out overwhelms a downstream API or rate limit. | Apply a concurrency limit or batch the work items. |
| The join result silently excludes failed parts. | Return explicit per-part status alongside the aggregate. |
07Implementations
Examples of products and frameworks that implement this pattern. Listed as evidence, not endorsement.
| Implementation | Mechanism |
|---|---|
| TemporalDurable execution engine | Parallel Activities or Child Workflows, joined in workflow code. |
| LangGraphAgent framework | The Send API dispatches parallel node runs; state reducers merge the results. |
| Apache AirflowWorkflow scheduler | Dynamic task mapping expands a task over inputs; a downstream task collects results. |
| PrefectWorkflow scheduler | task.map and submit run tasks concurrently; results are gathered in the flow. |
| AWS Step FunctionsCloud workflow service | Parallel and Map states run branches concurrently and collect outputs. |
| Azure Durable FunctionsCloud workflow service | Start activities in parallel and await them all before continuing. |
| DagsterWorkflow scheduler | Dynamic outputs map work over inputs and collect the results. |
| CamundaProcess orchestration (BPMN) engine | Parallel gateways and multi-instance activities split and join work. |