n8n-orchestration-patterns

n8n Orchestration Patterns (fan-out / fan-in / batch)

Battle-tested against the n8n docs (main) and real production workflows. The naive approach (branch-split) does NOT parallelize under the modern default — read the trap first.

---

The trap: branch-split alone does NOT parallelize

Mechanic	Behaviour
executeWorkflow mode: each	runs sequentially, one input item at a time
executeWorkflow mode: once	all items in one sub-workflow call
Workflow executionOrder: 'v1' (default ≥ 1.0)	completes one branch before starting the next
Workflow executionOrder: 'v0' (legacy)	first node of every branch, then second node of every branch — layer-by-layer, all branches interleaved
N8N_CONCURRENCY_PRODUCTION_LIMIT	does NOT apply to sub-workflow executions

So: 5 branches each [Filter → executeWorkflow] under executionOrder: 'v1' run serially — wall-clock = sum of all branches = no speedup. executeWorkflow mode: each is sequential per item.

---

Pattern A — executionOrder: 'v0' + branch-split (regular mode, no queue)

Layer-by-layer scheduling means when branch 0's executeWorkflow awaits (e.g. an LLM call), the engine schedules branch 1's, then 2,3,4 → all sub-workflow calls are in-flight at once (Node async I/O).

@workflow({
  name: 'Parallel Orchestrator',
  settings: {
    executionOrder: 'v0',     // ← CRITICAL — without this, branches run serially
    executionTimeout: 7200,
  },
})

Shape: a Code node assigns bucket: idx % N → N Filter nodes split by bucket → N executeWorkflow nodes → Merge (mode: append, numberInputs: N). Speedup ≈ N branches.

Caveat: v0 interleaving was less aggressive than expected for some (n8n issue #13620, closed "not planned"). On production-critical paths: measure, don't assume. Guaranteed N× only via queue mode.

Pattern B — Wait=OFF + DataTable fan-in ← RECOMMENDED

Cleaner than a resumeUrl callback: no webhook between workflows (org veto), no HMAC-signature pain, and a persistent audit trail. See n8n-autopilot:data-tables for the table CRUD.