D2 Automation Knowledge
A practical framework for deciding when n8n should orchestrate a workflow, when custom code should own core logic, and when a hybrid architecture is the safer choice.
Direct answer
Use n8n when orchestration, integration visibility and operational change speed matter more than owning every runtime detail. Use custom code when the workload is latency-sensitive, compute-heavy, tightly coupled to product logic or requires controls that do not fit a visual workflow. In many production systems, the strongest boundary is hybrid: n8n coordinates events and systems while small code services own specialized logic.
Engineering model
Decision boundary = orchestration complexity + change frequency + observability need + throughput/latency constraints + ownership of core business logic
01 / Design rule
A workflow engine is strongest when it coordinates systems: receive an event, validate it, call APIs, move data, persist state, branch on explicit rules and surface failures. It is weaker when it becomes a container for large amounts of application logic simply because the team already knows the tool.
02 / Design rule
Routing, thresholds, deduplication and state transitions should remain explicit. If a rule is small and operational, n8n can be a good home. If the rule is a reusable domain engine with tests, versioning and high change risk, a code module or service often gives stronger control.
03 / Design rule
A hybrid design does not mean the architecture failed to choose. It means responsibilities are separated: n8n owns orchestration and operational visibility; an API or function owns the specialized algorithm; the database owns durable truth; queues own execution buffering when required.
04 / Design rule
A 10-node workflow can be harder to operate than a 100-node system if state and failure modes are implicit. Judge the design by ownership, recoverability, observability and evidence, not by how compact or visually impressive the canvas looks.
Implementation checklist
FAQ
Yes, when the system includes the reliability controls its workload requires: authentication, validation, idempotency, retry, persistence, observability and recovery. Production suitability depends on architecture and operations, not the canvas alone.
When a focused algorithm, parser, transformation, performance constraint or reusable domain rule is clearer and safer as a tested function or API than as a large visual expression.
Evidence standard
D2 publishes these boundaries explicitly. The methodology page explains what evidence is required before a system is described as implemented, validated or production-backed.
Read D2 evidence methodologyRelated system evidence
Apply the framework