Realtime data synchronisatie betekent dat een wijziging in het ene systeem binnen enkele seconden ook in het andere systeem staat. Dat is niet voor alle gegevens nodig: voorraad en orders hebben baat bij snelheid, terwijl productcontent en financiële boekingen prima elk uur of elke nacht kunnen. De juiste keuze per gegevensstroom bespaart je kosten, API-verkeer en storingen.
Realtime, near-realtime en batch: wat is het verschil?
In gesprekken over koppelingen wordt “realtime” vaak ruim gebruikt. Het helpt om drie niveaus te onderscheiden.
Realtime
Een wijziging wordt direct doorgegeven, meestal binnen een paar seconden. Dat gebeurt doorgaans via een webhook of event: het bronsysteem meldt zelf dat er iets veranderd is. Echt nul vertraging bestaat bij koppelingen tussen losse systemen niet, want er zit altijd netwerkverkeer en verwerking tussen.
Near-realtime
Wijzigingen worden in korte intervallen opgehaald, bijvoorbeeld elke 1 tot 15 minuten. Voor de meeste bedrijfsprocessen voelt dit als realtime, en het is vaak de verstandigste middenweg als een systeem geen webhooks ondersteunt.
Batch
Gegevens worden op vaste momenten in één keer verwerkt, bijvoorbeeld elk uur, elke nacht of één keer per week. Batch is eenvoudig, goed te controleren en belast systemen op rustige momenten. Het nadeel: tussen twee runs lopen systemen uit elkaar.
Webhooks, polling en geplande jobs
Achter die drie niveaus zitten drie technieken om een synchronisatie te starten.
- Webhooks. Het bronsysteem stuurt een bericht naar de integratie zodra er iets gebeurt, zoals een nieuwe order in Shopify. Snel en zuinig met API-verkeer, maar je bent afhankelijk van het bronsysteem: een gemiste of dubbele webhook moet je zelf opvangen.
- Polling. De integratie vraagt op een vast interval: “wat is er veranderd sinds de vorige keer?” Dat werkt met vrijwel elke API, mits het systeem kan filteren op wijzigingsdatum. Te vaak pollen kost onnodig veel API-calls.
- Geplande jobs. Een taak die op een vast tijdstip draait, bijvoorbeeld een volledige prijslijst om 02:00 uur. Vaak via een bestand of een bulk-API.
Een goede opzet combineert ze vaak. Je gebruikt webhooks als snel signaal en draait daarnaast periodiek een controle die gemiste wijzigingen alsnog oppakt. Zo krijg je snelheid zonder dat één gemist bericht ongemerkt tot verkeerde gegevens leidt. Meer over de techniek erachter lees je in het artikel over API koppelingen.
Welke gegevens hebben welke snelheid nodig?
De vraag is niet “willen we realtime?”, maar “wat kost het als dit gegeven een uur achterloopt?” Deze tabel is een gangbaar vertrekpunt voor webshops en groothandels.
| Gegevens | Advies | Waarom |
|---|---|---|
| Voorraad | Realtime of near-realtime | Voorkomt verkoop van producten die er niet meer zijn, zeker bij meerdere kanalen en marketplaces |
| Orders naar ERP of WMS | Realtime of elke paar minuten | Hoe eerder de order in het magazijn staat, hoe eerder hij de deur uit kan |
| Orderstatus en track-and-trace | Near-realtime | Klanten verwachten snel een verzendbevestiging |
| Prijzen | Per uur of per nacht, direct bij acties | Prijzen wijzigen meestal gepland, maar een fout moet snel te herstellen zijn |
| Productcontent | Per uur of per nacht | Teksten en afbeeldingen zijn niet tijdkritisch en vaak groot in volume |
| Klantgegevens | Bij wijziging of per uur | Belangrijk voor B2B-prijsafspraken en kredietlimieten |
| Financiële boekingen | Per dag | Een dagelijkse batch is beter te controleren en aan te sluiten |
Een voorbeeld: bij een WMS koppeling is snelheid op voorraad en orders cruciaal, terwijl een PIM koppeling productdata prima elk uur kan bijwerken. Ook binnen één stroom kun je differentiëren: een voorraadwijziging naar nul stuur je direct door, een kleine correctie mag meeliften met de volgende run.
API-limieten: de grens van realtime
Bijna elke SaaS-applicatie beperkt hoeveel verzoeken je per seconde, minuut of dag mag doen. Shopify werkt met een bucket-systeem en rekent bij GraphQL met kosten per query. Exact Online hanteert limieten per minuut en per dag per administratie. Business Central en veel andere pakketten hebben vergelijkbare grenzen.
Dat heeft directe gevolgen. Wie elke minuut 10.000 artikelen één voor één opvraagt, zit al snel aan de limiet, waarna verzoeken worden geweigerd. Slimme synchronisatie haalt daarom alleen gewijzigde records op (een delta), bundelt wijzigingen in bulkverzoeken en wacht netjes als het systeem aangeeft dat de limiet is bereikt. Kijk bij een Exact koppeling of een Shopify koppeling altijd eerst naar de actuele limieten in de documentatie van de leverancier, want die worden regelmatig aangepast.
Kosten en complexiteit
Realtime klinkt als altijd beter, maar het heeft een prijs:
- Meer bewegende delen. Webhooks moeten worden ontvangen, gecontroleerd, in een wachtrij gezet en verwerkt. Bij batch is er één taak die start en eindigt.
- Meer verkeer. Elke kleine wijziging is een los bericht. Bij veel volume kan dat hogere licentiekosten of zwaardere infrastructuur betekenen.
- Lastiger testen. Een batch kun je opnieuw draaien en vergelijken. Een stroom van losse events volg je minder makkelijk na.
- Volgorde. Komt “order geannuleerd” binnen vóór “order aangemaakt”, dan moet de integratie daar raad mee weten.
Batch is daarentegen niet gratis: tussen twee runs werk je met verouderde gegevens, en een fout in de nachtrun ontdek je pas de volgende ochtend. De kunst is per stroom de eenvoudigste oplossing te kiezen die snel genoeg is.
Foutafhandeling en idempotentie
Hoe snel een koppeling ook is, er gaat vroeg of laat iets mis: een systeem is even offline, een time-out, een ongeldig veld. Een betrouwbare synchronisatie is daarop voorbereid.
Retries met wachttijd
Bij een tijdelijke fout probeert de integratie het opnieuw, met steeds iets meer wachttijd tussen de pogingen. Blijft het misgaan, dan komt het bericht in een foutenlijst en krijgt iemand een melding. Zo raakt er niets kwijt en blijft een storing niet onopgemerkt.
Idempotentie
Webhooks worden vaak “minstens één keer” afgeleverd, dus soms ook twee keer. En een retry kan een bericht opnieuw versturen dat de eerste keer eigenlijk wel was aangekomen. Een idempotente verwerking zorgt dat hetzelfde bericht twee keer verwerken hetzelfde resultaat geeft als één keer. In de praktijk: controleer op een uniek kenmerk zoals het ordernummer of een event-ID voordat je iets aanmaakt, en werk een record alleen bij als de wijziging nieuwer is dan wat je al hebt.
Controle achteraf
Laat periodiek een vergelijking draaien tussen bron en doel, bijvoorbeeld een nachtelijke check of alle orders van gisteren in het ERP staan. Zo vang je stille fouten op die geen melding gaven.
Drie voorbeelden uit de praktijk
Webshop met meerdere marketplaces. Voorraad komt uit het WMS en wordt bij elke mutatie via een event naar de webshop en de marketplaces gestuurd. Orders komen via webhooks binnen en gaan direct naar het ERP. Een nachtelijke volledige voorraadsync corrigeert eventuele afwijkingen.
B2B-groothandel met klantspecifieke prijzen. Prijsafspraken wijzigen een paar keer per maand. Een run elke nacht is genoeg, met de mogelijkheid om handmatig een directe sync te starten bij een prijsfout. Orders uit de B2B-portal gaan elke vijf minuten via polling naar het ERP, omdat het ERP geen webhooks ondersteunt.
Productdata vanuit een PIM. Content wordt elk uur als delta naar de webshop gestuurd, alleen voor producten die volledig zijn verrijkt. Afbeeldingen en grote bestanden gaan ’s nachts, zodat de webshop overdag niet wordt belast.
Synchronisatie laten inrichten
Twijfel je welke stroom realtime moet en welke niet? Wij kijken per gegevensstroom naar volume, API-limieten en de gevolgen van vertraging, en bouwen de koppeling bij voorkeur op Alumio met retries, monitoring en logging standaard ingebouwd. Lees ook het overzicht over software integratie, bekijk de tarieven of plan een gratis datascan van ongeveer 45 minuten via contact.
