Learn n8n - Core Concepts & n8n Architecture

#Introduction

In episode 1 you understood what n8n is, its history, and why it deserves to be chosen. Now it's time to open the hood: how n8n actually works on the inside.

This episode covers n8n's core concepts and architecture — the principles of node-based workflows and DAG execution, the types of nodes (trigger, action, function, and workflow nodes), as well as the internal workings including the execution queue, error handling, and retry. After this episode, you'll read an n8n workflow structure like reading a map, not a puzzle.

#The Principles of Node-Based Workflows and DAG Execution

#Workflows as a Chain of Nodes

In n8n, a workflow is a chain of connected nodes. One node represents one step: it receives input, processes it, then produces output. Data flows following the direction of connections from the trigger at the start to the final node.

The first key concept: n8n executes flows shaped like a DAG (Directed Acyclic Graph) — a directed graph without cycles. This means:

• Data flows one way from node to node.
• There are no infinite loops at the structure level (loops are created explicitly with nodes like SplitInBatches).
• Workflows can branch — one node can forward to many destination nodes.

{
  "name": "contoh-dag",
  "nodes": [
    { "name": "Webhook", "type": "n8n-nodes-base.webhook", "typeVersion": 2 },
    { "name": "HTTP Request", "type": "n8n-nodes-base.httpRequest", "typeVersion": 4 },
    { "name": "IF", "type": "n8n-nodes-base.if", "typeVersion": 2 }
  ],
  "connections": {
    "Webhook": { "main": [[{ "node": "HTTP Request" }]] },
    "HTTP Request": { "main": [[{ "node": "IF" }]] }
  }
}

The structure above is the native representation of a workflow in n8n: the nodes array contains the definition of each node, and the connections object describes who connects to whom. Reading this format — which you can export at any time — helps you understand that the visual editor is just a map of this data. In practice, a workflow can be exported to a JSON file with n8n export:workflow and imported back with n8n import:workflow.

#How Execution Runs

When a trigger fires an execution, n8n runs the nodes in DAG order. Each node receives items — an array of JSON objects — from its input, processes them, then sends the results to the next node. This single execution is recorded, complete with each node's output, so it can be audited and debugged later.

#Types of Nodes

Nodes in n8n can be categorized by their role:

This breakdown is important for reading other people's workflows quickly: the moment you see a Webhook node at the start, you immediately know it's a trigger; an HTTP Request node in the middle is an action; an IF node is a branch.

A real example: to process custom data, you place a Code node that receives an array of items and returns a new array:

Code node untuk transformasi

const nama = $json.nama || "anonim";
const pesan = `Halo, ${nama}!`;
return [{ json: { pesan, waktu: Date.now() } }];

Every element returned must have a json key. This pattern is what makes n8n flexible — you're not limited to visual configuration, you can write logic directly.

#n8n's Internal Architecture

Behind the scenes, n8n is made up of several main components:

• Editor UI — a Vue-based frontend that provides the drag-and-drop canvas.
• Workflow engine / core — the Node.js backend that executes nodes and produces executions.
• Credential store — encrypted storage for credentials, locked with an encryption key.
• Database — stores workflows, credentials, and execution history. SQLite by default; for production, PostgreSQL or MySQL.
• Worker (optional) — additional instances for queue mode that process executions in parallel and in a distributed fashion.

In standard (main-process) mode, a single n8n instance does everything — UI, execution, and storage. For large scale, queue mode separates execution into a Redis queue and separate workers, so the UI doesn't stutter under high load. We'll break down this scaling detail in the self-hosting episode.

#Error Handling and Retry at the Engine Level

Executions rarely run smoothly without a hitch. n8n handles failures on several layers:

• Default behavior — if a node fails, the execution stops and is marked as failed. The output from nodes that succeeded is still preserved.
• Retry On Fail — retries a failed node several times with delays; useful for transient errors like timeouts or rate limits.
• Continue On Fail — continues the execution even if a node fails, outputting an error object in the item.
• Error Workflow — a separate workflow run when the main workflow fails, for notifications and recovery.

These concepts are the foundation of "hardy workflows" whose practical implementation you'll learn in the error handling episode. For now, just remember: failure isn't the end — n8n gives you many levers to decide what happens after an error.

#The Execution Flow from Trigger to Output

Let's summarize all the concepts into one real execution flow:

1. Trigger fires — a webhook receives an HTTP request, or a cron schedule arrives.
2. Items are created — the payload data is turned into JSON items that become the first node's input.
3. Nodes execute in sequence — the engine runs each node following the direction of the connections, branching according to the DAG.
4. Output is recorded — each node's output is saved as part of the execution history.
5. Done or failed — the execution is marked successful, stops due to an error, or is diverted to an error workflow.

This flow applies to almost every workflow, from the simplest to complex production pipelines.

#Closing

This episode opened n8n's black box: a workflow is a DAG of nodes, each processing an array of JSON items; nodes are categorized into trigger, action, function, workflow control, and helper; behind it all stand the engine, credential store, database, and worker; and failures are handled through retry, continue on fail, and error workflows.

Key takeaways:

• An n8n workflow is a DAG — data flows one way, branching without cycles.
• Data between nodes is always an array of items with json and binary keys.
• Nodes are divided into trigger, action, function, workflow control, and helper.
• The core architecture consists of the editor, engine, credential store, database, and worker.
• Errors are handled through retry, continue on fail, and error workflows.

In the next episode, we'll get down to practice: installation and basic setup — running n8n locally, self-hosted options with Docker Compose, Kubernetes, and n8n Cloud, plus setting up the credential store, environment variables, and basic configuration. See you there!