Realtime synchronisatie of batch: hoe snel moet je data mee?

Je wilt data tussen twee systemen synchroniseren en dan komt de vraag: hoe snel moet het? Direct, elke vijf minuten, elk uur of één keer per dag? Realtime synchronisatie klinkt als de beste keuze, maar sneller betekent ook complexer en meer beheer. De kunst is per proces kiezen wat nodig is, niet wat technisch het mooist is.

Wat is het verschil tussen realtime synchronisatie en batch?

Bij realtime synchronisatie wordt een wijziging direct doorgezet, meestal binnen enkele seconden. Het bronsysteem stuurt een signaal, een webhook, zodra er iets verandert, en dat signaal start de synchronisatie.

Bij batchsynchronisatie wordt op vaste momenten alle nieuwe of gewijzigde data opgehaald en in één keer verwerkt. Het doelsysteem vraagt periodiek aan de bron wat er veranderd is. Dat heet polling.

Daartussen zit near realtime: elke minuut, elke vijf minuten of elk kwartier controleren. Voor veel processen is dat de beste balans.

Wanneer heb je realtime synchronisatie nodig?

Realtime is de juiste keuze als vertraging direct problemen geeft. Dat speelt vooral in vier situaties.

• De klant wacht erop. Een bestelling moet direct bevestigd worden, een betaling moet direct toegang geven tot een account of download.
• Beschikbaarheid bepaalt wat je verkoopt. Voorraad in een webshop of vrije plekken in een boekingssysteem. Loopt dat achter, dan verkoop je wat je niet hebt.
• Een actie moet direct stoppen. Een opgezegd abonnement of ingetrokken toegang wil je niet pas morgen verwerken.
• Volgorde en volledigheid zijn kritiek. Bij financiële transacties en logging wil je geen gaten.

Wanneer is batchsynchronisatie genoeg?

Batch volstaat als niemand merkt dat data een uur of een dag oud is. Dat geldt voor meer processen dan je zou denken.

• Rapportages. Een dashboard met dagcijfers hoeft niet per seconde bij te werken.
• Archivering en back-ups. Een nachtelijke run is prima.
• Grote hoeveelheden data. Duizenden records verwerk je efficiënter in één run dan record voor record.
• Systemen zonder webhooks. Sommige software kan geen signaal sturen bij een wijziging. Dan is polling de enige route.

Waarom is realtime complexer?

Realtime synchronisatie vraagt meer van een koppeling dan de meeste mensen verwachten.

Webhooks moeten betrouwbaar aankomen

Wat als het ontvangende systeem even niet bereikbaar is? Zonder wachtrij en herhaalpogingen raak je data kwijt. Een robuuste koppeling vangt dat op en verwerkt het signaal later alsnog.

De volgorde kan door elkaar raken

Komen twee wijzigingen vlak na elkaar binnen, dan kan de tweede eerder verwerkt worden dan de eerste. Voor een adreswijziging maakt dat weinig uit, voor een voorraadmutatie wel.

Pieken komen tegelijk binnen

Een actie in je webshop betekent honderden wijzigingen in korte tijd, en dus honderden synchronisaties tegelijk. De koppeling en de API's aan beide kanten moeten dat aankunnen, inclusief hun limieten op het aantal verzoeken.

Meer verwerkingen, meer gebruik

Tools als Make en Zapier rekenen per uitgevoerde taak. Realtime synchronisatie genereert veel meer taken dan een run per uur.

Batch heeft zijn eigen aandachtspunten. Een grote run kan langer duren dan het interval, en een fout ontdek je pas bij de volgende run. Logging en meldingen horen daarom bij beide varianten.

Kun je realtime en batch combineren?

Ja, en meestal is dat de beste oplossing. Niet elke datastroom in een organisatie heeft dezelfde snelheid nodig. Een webshop met een extern voorraadsysteem is een goed voorbeeld:

• Voorraadniveaus gaan realtime naar de website, zodat niets verkocht wordt dat op is.
• Bestellingen gaan near realtime naar het magazijn, elke paar minuten. Het magazijn werkt niet per seconde.
• Verkoopcijfers gaan één keer per dag naar de rapportage.

Drie frequenties voor drie behoeften. Zo houd je de koppeling zo eenvoudig als kan en zo snel als nodig.

Hoe kies je de juiste frequentie?

Deze vragen geven meestal snel duidelijkheid:

1. Wat gaat er mis als de data een uur oud is in plaats van een seconde? Als het antwoord is dat er niets ergs gebeurt, hoeft het niet realtime.
2. Wie gebruikt de data? Klanten verwachten snelheid, interne rapportages kunnen wachten.
3. Hoeveel wijzigingen verwacht je? Bij tientallen per dag maakt de keuze weinig uit, bij duizenden per uur wel.
4. Kan het bronsysteem webhooks sturen? Zo niet, dan valt echte realtime af of is een tussenoplossing nodig.
5. Wie houdt de koppeling in de lucht? Realtime vraagt meer bewaking.

Onze aanpak

We beginnen bij de vraag wat een proces echt nodig heeft. Realtime bewaren we voor stromen waar vertraging schade doet, batch voor alles waar snelheid niet uitmaakt, en near realtime voor het grote middengebied. Dat maakt koppelingen eenvoudiger in beheer en minder foutgevoelig.

De basis lees je in ons artikel over data synchroniseren tussen systemen. Wil je sparren over jouw situatie, bekijk dan onze aanpak voor systeemkoppelingen.