Workflow runtime kiezen: Temporal, Inngest of BullMQ

De zondagavond-vraag van 21:00

Het is zondagavond, net na 21:00. Het wekelijkse performance rapport voor je grootste retainer is niet verstuurd. Het Slack-kanaal waar het zou moeten verschijnen blijft leeg. Je opent het queue-dashboard en ziet één regel met processing, met een spinner die al veertig minuten draait.

Je weet niet of de workflow vastzit, stilletjes is gecrasht, of de Meta Ads API de export-stap heeft rate-limited, of dat Looker Studio plat ligt. Je bent geen backend engineer. Je bent hoofd operations. De backend engineer die dit heeft gebouwd woont in Rotterdam en zit in een vliegtuig naar Lissabon.

Tegen de tijd dat iemand de echte logs leest, wordt de klant maandagochtend wakker zonder rapport. Dit is het moment dat bepaalt welke workflow runtime een bureau moet kiezen. Niet de benchmark. Niet de marketingpagina. Dit moment, om 21:00, zonder engineer beschikbaar.

Drie kandidaten voor de rapportagelaag

Voor een Nederlands bureau dat tussen de 200.000 en 350.000 workflow-executies per maand draait (wekelijkse klantrapporten, maandelijkse facturatieruns, dagelijkse pulls vanuit ad-platforms), domineren drie opties het gesprek in 2026.

• Temporal, een durable execution engine met een worker pool. Je schrijft workflows als code, Temporal regelt retries, timers en state replay.
• Inngest, een event-driven workflow platform met een managed control plane, terwijl je functies op je eigen infrastructuur draaien.
• BullMQ op Redis Streams, een Node-native queue die je zelf draait, met alle lijmcode geschreven door je eigen team.

Alle drie kunnen ze dezelfde rapportage-workflow draaien. De keuze gaat niet over wat ze kunnen. De keuze gaat over wat als eerste breekt, wie het merkt, en hoe lang het duurt om de kapotte stap te vinden als de engineer onbereikbaar is.

Kosten per run bij 280k executies per maand

Kosten is de as die iedereen als eerste scoort, omdat het de makkelijkste is om te berekenen. Hier een schatting op de achterkant van een bierviltje voor een bureau onder de €15M, dat ongeveer 280.000 executies per maand draait, uitgaande van vijf tot zeven stappen per rapportage-workflow. De cijfers hieronder dekken vendor-kosten plus compute op de eigen cloud-account van het bureau.

Runtime                Vendor /mnd  Compute /mnd  Totaal /mnd  Per run
Temporal Cloud         ~€180        ~€80          ~€260        €0.00093
Inngest (Team tier)    ~€70         ~€40          ~€110        €0.00039
BullMQ + Redis (self)  €0           ~€90          ~€90         €0.00032

De spreiding lijkt dramatisch in percentages en triviaal in euro's. De goedkoopste en de duurste optie verschillen ongeveer €170 per maand. Dat zijn twee engineer-uren tegen een normaal Nederlands bureautarief. Als de goedkopere runtime je drie engineer-uren per incident kost, ben je geld aan het verliezen voordat je iets oplevert.

Standaard paging bij incidenten

De tweede as is incident-routing. Elke runtime heeft een andere default voor wat er gebeurt als een workflow zijn SLA mist.

Bij BullMQ heb jij de SLA-check geschreven. Heb je dat niet gedaan, dan is er geen check. Heb je het wel gedaan, dan paget die wie jij hebt aangesloten. Dat is het eerlijke antwoord: je krijgt precies wat je hebt gebouwd, en de on-call rotatie is welke engineer toevallig als eerste Slack leest.

Temporal heeft workflow- en activity-timeouts als first-class primitives. Je kunt declareren dat een weekly_report workflow binnen zes uur klaar moet zijn. Daarna raised Temporal een timeout-event in de workflow history. Je moet dat event nog wel doorsturen naar PagerDuty of OpsGenie, maar de detectie is automatisch en met de visibility API kun je elke vastgelopen run in één query oplijsten.

Inngest komt het dichtst bij vuurt een webhook naar je incident-kanaal by default. Step-level failures verschijnen in het dashboard met een stack trace, en het platform kan naar Slack posten of een functie aanroepen wanneer een run zijn gedeclareerde duur overschrijdt, zonder custom bedrading.

Leesbaarheid voor de ops lead

Dit is de as die niemand benchmarked. Het is ook de as die over een jaar stilletjes de meeste engineer-uren kost.

Open het Inngest dashboard op het moment van een failure. Je ziet een verticale timeline. Stap één, fetch_meta_ads_data, groen vinkje, 240ms. Stap twee, fetch_google_ads_data, rood kruis, ETIMEDOUT after 30s. Een ops lead kan dat lezen. Ze kan doorklikken op de gefaalde stap en zien Google Ads API returned 502. Ze weet dat ze het rapport maandagochtend opnieuw moet draaien. Geen engineer nodig.

Open Temporal's UI voor dezelfde failure. Je ziet een event history met namen als WorkflowTaskCompleted, ActivityTaskScheduled, ActivityTaskFailed. De informatie is er, maar de vocabulaire is engineering-vocabulaire. Een ops lead die hierop niet is ingewerkt vertaalt het niet zonder hulp.

De gebundelde UI van BullMQ, of het populaire Bull Board, toont queue-positie, resterende pogingen en de error-string als je die hebt gelogd. Het is de spartaanste van de drie. Of de ops lead 'm kan lezen hangt volledig af van wat je engineer toevallig had besloten te loggen op die woensdag in maart toen ze de worker schreef. De BullMQ documentatie is daar helder over: observability is jouw probleem.

Het scoreformulier dat we echt gebruiken

Hier de scorekaart die we met elke bureau-klant doorlopen voordat we ons committeren aan een runtime. Score één tot vijf op elke as, vermenigvuldig met het gewicht, tel de totalen op.

axes:
  - name: per_run_cost_at_target_volume
    weight: 2
    note: "Vendor plus compute bij verwacht maandelijks volume"

  - name: ops_lead_can_read_trace_unaided
    weight: 4
    note: "Zondag 21:00 test: kan een niet-engineer de kapotte stap vinden?"

  - name: incident_paging_out_of_box
    weight: 3
    note: "Paget een vastgelopen workflow iemand zonder custom code?"

  - name: setup_cost_in_engineer_days
    weight: 2
    note: "Eerste productie-workflow end-to-end opgeleverd"

  - name: lock_in_risk
    weight: 1
    note: "Hoeveel dagen om af te migreren als de prijzen veranderen?"

Let op de gewichten. Kosten is een twee. Leesbaarheid is een vier. Dat is de expliciete positie: bij dit volume domineert de leesbaarheids-as de rekensom, want elke minuut dat de ops lead niet zelf kan debuggen is een minuut die tegen een engineer wordt geboekt.

Sterkste fit per scenario

Run de scorekaart eerlijk en er ontstaat een van drie beelden.

Inngest wint wanneer een ops lead het rapportageproces al met de hand draait en weet wat elke stap zou moeten opleveren. De timeline-view laat die persoon doorgaan met debuggen zonder de engineer te pagen. De vendor-kosten zijn de hoogste van de goedkope opties, maar de headcount-som slaat snel in zijn voordeel om.

Temporal wint wanneer workflows langer zijn, doorlooptijden zich uitstrekken over dagen (meerdaagse wachttijden voor klantgoedkeuring, langzaam rollende content-pipelines), of wanneer een audit trail belangrijk is voor compliance. Het replayable execution model en de rijke event history van Temporal worden door de andere twee niet geëvenaard. Het is ook de juiste keuze als je al een backend team hebt dat de controle wil. Het is niet de juiste keuze voor het 21:00-zondagscenario waarmee dit stuk opent.

BullMQ wint voor bureaus onder ongeveer 100.000 executies per maand, met een engineer die de queue-laag actief wil bezitten en bereid is om de paging, de timeouts en het dashboard zelf te schrijven. De onderhoudskosten staan permanent in de agenda van je team.

De vijf-minuten screenshot-test

Open het dashboard van welke runtime je ook neigt. Maak een screenshot van wat het dashboard toont op het moment dat een workflow faalt. Stuur de screenshot naar je ops lead. Stel één vraag: kun je me vertellen welke stap brak en wat je eraan moet doen, zonder hulp van mij?

Is het antwoord nee, dan heb je je data. Score het formulier en kies opnieuw.

Toen we eerder dit jaar de klantrapportage-laag bouwden voor een Amsterdams paid-media bureau, was waar we tegenaan liepen dat hun ops lead het zondagproces al twee jaar handmatig had gedraaid en de workflow beter kende dan iedereen aan de engineering-kant. De winst zat 'm niet in de engine. De winst zat 'm in procesautomatisering die step-level failure liet zien in de taal die zij al gebruikte.