Een van de meest onderschatte beslissingen bij het bouwen van automation-workflows is de keuze voor de juiste integratiestijl. Kies je verkeerd, dan bouw je iets dat aanvankelijk werkt maar later vastloopt op schaalbaarheid, foutafhandeling of onderhoudbaarheid. In dit artikel leg ik de drie meest gebruikte stijlen uit en geef ik je een beslismodel.
Kort door de bocht: REST polling voor eenvoudige, niet-tijdkritische integraties. Webhooks voor realtime triggers bij externe systemen. Event-driven architectuur voor complexe, hoge-volume workflows waar betrouwbaarheid kritisch is.
De drie integratiestijlen uitgelegd
REST Polling
- Jij vraagt periodiek om data
- Eenvoudig te implementeren
- Altijd beschikbaar (pull)
- Vertraagd (interval)
- Inefficiënt bij laag volume
Webhooks
- Systeem pusht bij event naar jou
- Realtime verwerking mogelijk
- Geen onnodige API-calls
- Vereist publiek endpoint
- Geen garantie op delivery
Event-driven
- Via message broker (Kafka, RabbitMQ)
- Gegarandeerde delivery
- Hoge schaalbaarheid
- Complexer in opzet
- Hogere infrastructuurkosten
REST polling: wanneer en hoe
REST polling is het meest eenvoudig: jouw automation-platform roept op gezette tijden een API aan om te kijken of er nieuwe data is. Dit is de juiste aanpak als:
- Het bronsysteem geen webhooks ondersteunt (veel legacy-systemen)
- De latentie niet kritisch is — een vertraging van 5–15 minuten is acceptabel
- Het volume laag is (minder dan een paar honderd records per uur)
De grootste valkuil bij polling is inefficiëntie: als je elke minuut een API aanroept maar er maar één keer per uur iets verandert, doe je 59 onnodige calls. Plan altijd het juiste interval op basis van de werkelijke frequentie van wijzigingen.
Webhooks: push in plaats van pull
Webhooks draaien de relatie om: in plaats van dat jij vraagt, stuurt het bronsysteem een bericht zodra er een event plaatsvindt. Dit is de juiste keuze als:
- Realtime of near-realtime verwerking vereist is
- Het bronsysteem webhooks ondersteunt (Stripe, GitHub, Shopify, etc.)
- Het volume hoogfrequent is maar onregelmatig verdeeld
De kritieke zwakte van webhooks: geen delivery-garantie
Webhooks zijn "fire and forget". Als jouw endpoint tijdelijk offline is wanneer het event plaatsvindt, mis je het bericht. De meeste webhook-aanbieders bieden retry-mechanismen, maar die zijn niet altijd betrouwbaar en hebben limieten. Oplossingen:
- Idempotency keys implementeren zodat herhaalde verzending geen duplicaten veroorzaakt
- Webhook event log bijhouden in een database voor reconciliatie
- Backup polling als fallback voor gemiste events
Event-driven architectuur: voor serieus werk
Wanneer jouw automation-platform deel uitmaakt van een kritisch bedrijfsproces waarbij geen enkel event verloren mag gaan, is een message broker de juiste keuze. Populaire opties zijn Apache Kafka, RabbitMQ en AWS SQS.
Het principe: producers schrijven events naar een queue of topic. Consumers verwerken die events in hun eigen tempo. De broker garandeert dat elk event minstens één keer wordt verwerkt — ook als een consumer tijdelijk uitvalt.
Wanneer event-driven de juiste keuze is
- Meerdere systemen moeten op hetzelfde event reageren (fan-out)
- Hoge volumes: 10.000+ events per uur
- Gegarandeerde verwerking is zakelijk vereist (financiële transacties, medische data)
- Je hebt verschillende consumers met verschillende verwerkingstijden
Praktijkvoorbeeld: logistieke orderverwerking
Bij DHL Nederland verwerken we dagelijks 80.000+ orderstatuswijzigingen. Een REST polling-aanpak zou dit systeem overbelasten. Webhooks zouden te veel risico geven op verloren events. De oplossing: alle statuswijzigingen worden geschreven naar een Kafka-topic. Drie consumers lezen dezelfde events: één voor klantkommunicatie (sms/e-mail), één voor WMS-updates, één voor finance-rapportage. Ze verwerken elk op hun eigen snelheid — geen van allen kan events missen.
Het beslismodel in één overzicht
Stel jezelf deze vragen:
- Ondersteunt het bronsysteem webhooks? Nee → gebruik polling. Ja → ga naar vraag 2.
- Is delivery-garantie zakelijk kritisch? Nee → webhooks volstaan. Ja → ga naar vraag 3.
- Is het volume meer dan 10.000 events per dag? Nee → webhooks + event log volstaan. Ja → event-driven met message broker.
Valkuil: Kies niet voor event-driven architectuur omdat het "modern" klinkt. De complexiteit is reëel — het verhoogt de leercurve, de infrastructuurkosten, en de operationele last. Gebruik het alleen als de use case het rechtvaardigt.