n8n, Make of Node: 50k events per dag, drie maanden later

Het merk verkoopt woonaccessoires. Omzet tussen de vijf en tien miljoen, een magazijn in Rotterdam, vier marketplaces, één Shopify-storefront. Elk klantcontact triggert een event. Bestelling geplaatst. Verzending aangemaakt. Retour gescand. Review achtergelaten. Refund verwerkt. Op een normale dinsdag zo'n 50.000 stuks. Vorig jaar piekte Black Friday op 380.000 in achttien uur.

Die events fanout naar zeven downstream-systemen. ERP. Boekhouding. E-mailtool. Support desk. BI warehouse. Review aggregator. En een Slack-kanaal waar de operations lead anomalieën in de gaten houdt. Het meeste is plumbing. Niet interessant tot er iets stuk gaat.

Toen we afgelopen september binnenkwamen, draaide het merk op Make. Twee jaar eerder was dat de juiste keuze geweest, met 4.000 events per dag en een marketingstagiair die scenario's aan elkaar plakte in de visuele builder. Inmiddels liep de maandfactuur boven de €1.400 en had één scenario in een weekend stilletjes 1.200 refund-webhooks laten vallen. De operations lead stelde één vraag. Make houden, naar n8n, of een Node worker bouwen. Kies.

We hebben alle drie gedaan, twee weken per stuk, in production shadow mode. Dit zagen we.

De workload die we maten

Een typisch eventpad ging zo. Shopify vuurt orders/create. De pipeline verrijkt de payload met de lifetime value van de klant uit BigQuery, draait een fraude-regel, post naar het ERP, queue't een transactionele e-mail, schrijft een regel weg in het BI warehouse, en zet een tag terug op de Shopify-klant. Zes externe calls. Eén conditional branch. Twee retry-paden bij failure.

50.000 events per dag met zes calls elk is 300.000 uitgaande API-calls per dag. Dat tweede getal maakte de keuze ingewikkeld.

Ronde één: Make op het nieuwe volume

Make rekent per operation, en elke module in een scenario telt mee. Het order-enrichment scenario was elf modules breed. Bij 50k events per dag is dat 550.000 operations per dag. Vijftien en een half miljoen per maand.

De openbare prijzen van Make verdwijnen zodra je een paar miljoen ops per maand passeert, dus we vroegen een quote op. Het was serieus geld. In die quote zat ook een fair-use plafond op parallelisatie dat de Black Friday-piek zou hebben afgeknepen.

Het grotere probleem was zichtbaarheid. Toen het refund-scenario stilletjes 1.200 webhooks liet vallen, kwam de failure naar boven als een rij rode stippen in de scenariohistorie. Geen alert. Geen Slack-ping. De error handler was twee refactors geleden tegen de verkeerde webhook-ID aangezet en niemand had het pad sindsdien getest. Je kunt dit in Make oplossen, maar je moet er wel aan denken om het op te lossen in Make. De kosten van die institutionele kennis zijn onderdeel van waar je echt voor betaalt.

Make bleef snel. De visuele builder is echt goed voor de eerste zes maanden van een workflow. Het probleem is dat de workflow geen zes maanden oud blijft.

Ronde twee: n8n self-hosted op één VM

We zetten een DigitalOcean droplet op met 4 vCPU en 16GB, draaiden n8n in Docker achter Caddy, lieten Shopify-webhooks op een staging-endpoint wijzen, en shadow-runden dezelfde elf-stappen pipeline tegen een kopie van het productieverkeer.

n8n op 50k events per dag was niet meteen prima. De standaard SQLite executions-database begon onder load te locken rond 8.000 executions per uur. We zijn overgegaan op Postgres, hebben overgeschakeld naar queue mode (het worker-model van n8n met Redis), en de bak hield het. CPU bleef rond de 35% op een normale dinsdag. We hebben een synthetische load-test gedraaid op 4× Black Friday-volume. Hield het ook.

De queue-mode setup was het saaie soort werk. Eén main-instance voor de webhooks en de UI, drie worker-containers die jobs van Redis trekken, Postgres voor execution history, restart policies, een health check op /healthz. Niets moeilijks aan. Maar het is wel allemaal van jou.

# docker-compose excerpt for the n8n setup we ran
services:
  n8n-main:
    image: n8nio/n8n:latest
    environment:
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      N8N_PROTOCOL: https
      N8N_HOST: flows.brand.nl
    depends_on: [redis, postgres]

  n8n-worker:
    image: n8nio/n8n:latest
    command: worker --concurrency=10
    deploy:
      replicas: 3
    environment:
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres

Wat we fijn vonden: de workflows zijn JSON. Ze gaan in git. Pull requests zijn reviewbaar. We konden tests schrijven tegen de lastigere conditional branches door een workflow te exporteren, er via de CLI een payload doorheen te jagen, en op de output te asserten. Dat alleen al dichtte het zichtbaarheidsgat dat het merk op Make in de kont had gebeten.

Wat we minder fijn vonden: de connector-library is kleiner dan die van Make, en een paar Nederlandse tools die het merk gebruikte (Mollie, Exact Online) hadden custom HTTP-request nodes nodig in plaats van first-party integraties. Dat kostte misschien twee engineering-dagen extra in de migratie. Niet gratis, maar ook niet rampzalig.

De infrakosten waren één droplet. €48 per maand, plus onze tijd.

Ronde drie: een Node worker op Cloud Run

De derde optie was wat de technische medeoprichter van het merk wilde. Workflow-tool eruit, een Node-service schrijven, deployen op Cloud Run, klaar.

We hebben 'm gebouwd. Fastify voor de webhook receiver, BullMQ op Redis voor de queue, een dunne handler-per-event-type structuur, OpenTelemetry voor traces. Ongeveer 1.400 regels TypeScript inclusief tests.

// handlers/orderCreate.ts
import { Job } from 'bullmq'
import { z } from 'zod'
import { enrichWithLtv, postToErp, queueEmail, writeWarehouseRow, tagCustomer } from '../svc'

const OrderCreate = z.object({ id: z.string(), customer: z.object({ id: z.string() }) })

export async function handleOrderCreate(job: Job) {
  const order = OrderCreate.parse(job.data)
  const ltv = await enrichWithLtv(order.customer.id)
  if (ltv.flag === 'fraud-suspect') return job.moveToFailed(new Error('fraud'), 'manual-review')
  await Promise.all([
    postToErp({ order, ltv }),
    queueEmail({ template: 'order-confirm', order, ltv }),
    writeWarehouseRow({ order, ltv }),
    tagCustomer({ id: order.customer.id, tag: ltv.tier }),
  ])
}

Het was de snelste van de drie. p95 end-to-end latency was 340ms, tegen 1,2s voor n8n en 2,8s voor Make. Cloud Run cold starts speelden geen rol omdat de workload de hele dag minstens één instance warm hield. De maandelijkse compute-rekening kwam onder de €30.

Maar snelheid was niet het punt. Het punt was dat de Node worker de enige optie was waarbij een nieuwe downstream-integratie een code review en een deploy betekende, niet een klik en een save. Dat is goed als het team de discipline aankan. Slecht als de marketingmanager op zondagavond om elf uur een nieuwe tag-customer stap wil toevoegen en de enige die kan deployen in een andere tijdzone zit.

We hebben ook ongeveer negen engineering-dagen verbrand om de worker op feature parity te krijgen. n8n kostte twee dagen. Make nul, want Make stond er al.

Het kostenplaatje, eerlijk

Zo zagen de drie maanden eruit in totale eigendomskosten, genormaliseerd op 'lever dezelfde elf-stappen pipeline, draai 'm op 50k events per dag, houd 'm twaalf maanden lopend':

• Make: ~€1.800/mnd aan operations + 0 engineering-dagen migratie + zo'n 2 dagen per maand operationele toil om gefaalde scenario's achterna te zitten. Ongeveer €25k per jaar all-in.
• n8n self-hosted: ~€60/mnd aan infra + 2 engineering-dagen migratie + 0,5 dag per maand toil. Ongeveer €5k per jaar all-in.
• Node worker: ~€30/mnd aan infra + 9 engineering-dagen migratie + 0,5 dag per maand toil + doorlopende devtijd voor elke nieuwe integratie. Ongeveer €8k in jaar één, daarna minder.

Die getallen zijn specifiek voor één merk. Bij 5k events per dag zien ze er anders uit (Make wint dan glashelder) en bij 500k events per dag waarschijnlijk ook (Node worker wint dan glashelder).

De vorm van de curve is wel consistent over alle per-operation leveranciers. Make, Zapier, n8n Cloud, Pipedream. Allemaal het goedkoopst als je workflowtelling in de honderden zit en je maandelijkse operations in de tienduizenden. Geen van allemaal de goedkoopste zodra je een miljoen ops per maand passeert. De prijzenpagina's stoppen rond die grens stilletjes met cijfers tonen, en dat is op zichzelf het signaal.

Wat we hebben opgeleverd

We kozen voor n8n. Self-hosted, Postgres erachter, queue mode, workflows in git. Op twee na hebben we alle Make-scenario's in twaalf werkdagen gemigreerd. De twee die we op Make lieten staan, waren edge-case marketing-automations die de marketingmanager end-to-end zelf beheerde. Geen reden om haar tool weg te nemen.

De migratie zelf was een zaterdagklus. Elk Make-scenario exporteren naar JSON, ze stuk voor stuk door een klein Python-vertaalscriptje halen dat we voor de terugkerende patronen hadden geschreven, de acht scenario's die het script niet aankon met de hand porteren, twee weken aan webhook-historie uit ons staging-archief replayen, de outputs vergelijken met de Make-kant, en aftekenen op de discrepanties die veilig te negeren waren (vooral timestamp-drift op de BI-regels). Zondagochtend stond het verkeer op n8n. De Make-scenario's bleven twee weken live met hun webhooks gericht op een swallowing endpoint, zodat we zonder deploy konden terugrollen.

De Node worker bleef in de repo staan, gedeployed naar een staging-omgeving, en handelt het ene pad af waar 340ms wél telde: realtime fraud-scoring op de checkout. Hybride stack. De juiste engine voor elke baan.

De verborgen kosten die niemand offreert

Wat alle drie de opties gemeen hebben, is dat het bouwen van de pipeline ongeveer 20% van de eigendomskosten is. De andere 80% zit in het jaar na de launch, als het ERP zijn webhook-schema verandert, de e-mailtool een endpoint uitfaseert, en een downstream-systeem tijdens de Sinterklaasdrukte 429s begint terug te geven.

De tool die je kiest is vooral een gok op wie je vertrouwt om die 80% op te vangen. Make vangt de operationele complexiteit voor je op en rekent per operation. n8n geeft je de engine en vraagt je de bak zelf te beheren. Een custom worker geeft je alles, en vraagt je alles te beheren.

Een audit van vijf minuten die je morgen kunt draaien

Open de execution log van je huidige workflow-tool. Filter op errors van de afgelopen 30 dagen. Beantwoord voor elke error twee vragen. Heeft iemand een alert gekregen? Heeft iemand er iets mee gedaan? Als het eerlijke antwoord op een van beide nee is, is dat je echte signaal, niet de prijzenpagina.

Toen we deze pipeline voor het merk hierboven bouwden, zat de winst niet in de tool-wissel. De winst zat in het doorprikken van het n8n failure-pad naar hetzelfde Slack-kanaal waar de operations lead toch al naar keek. Als je op het volume zit waar dit ertoe doet, doen wij dit soort procesautomatisering end-to-end; het draaiboek is hetzelfde of de engine nu n8n is, een Node worker, of allebei.