Je integratie draait elk uur en bidt
En hoopt dat er in die 59 minuten niets veranderde.
Ergens in je infrastructuur draait elke 60 minuten een cron job. Zijn taak is Systeem A met Systeem B verbinden. Hij haalt data uit het ene, transformeert ze en duwt ze naar het andere. Hij is geschreven door een developer die twee jaar geleden vertrok. Hij draait op een server die sindsdien niemand heeft herstart. Hij werkt. Meestal.
Op minuut 0 draait de sync. Hij kopieert je inventory van je warehousesysteem naar je salestool. Op minuut 12 wordt een toestel verkocht. Het warehousesysteem markeert het als verkocht. De salestool weet het nog niet — die weet het pas op minuut 60. Op minuut 35 ziet een koper in de salestool het toestel, denkt dat het beschikbaar is en start een onderhandeling. Op minuut 47 doet de koper een bod op een toestel dat 35 minuten geleden verkocht is.
Op minuut 60 draait de sync opnieuw. Het toestel verdwijnt uit de salestool. Het bod van de koper verwijst nu naar een spook. Iemand moet bellen. Het gesprek begint met "sorry, dat toestel is niet meer beschikbaar" en eindigt met een koper die zich afvraagt waarom je inventory altijd fout is.
De kloof van 59 minuten
Elke sync-gebaseerde integratie heeft een kloof: de tijd tussen een wijziging in het ene systeem en het moment waarop het andere systeem daarvan weet. Bij hourly syncs is die kloof maximaal 59 minuten. Bij daily syncs is het 23 uur en 59 minuten. Bij de integratie die "meestal 's nachts draait maar soms faalt en niemand checkt tot iemand klaagt" is de kloof existentieel.
De kloof is geen bug. Het is de architectuur. Sync jobs kopiëren een snapshot. Tussen snapshots verandert de wereld. Toestellen verkopen. Grades wijzigen. Orders vertrekken. Prijzen passen aan. De sync weet van niets tot hij opnieuw draait, naar de source kijkt en de huidige staat kopieert. Alles wat tussen de vorige en deze sync gebeurde, wordt samengeperst tot één update. De granulariteit van verandering gaat verloren. De volgorde van gebeurtenissen gaat verloren. Alleen de eindtoestand blijft over.
Een sync job integreert geen twee systemen. Hij geeft ze een gedeeld geheugen dat één keer per uur bijwerkt en hoopt dat het uur rustig was.
De fout die je niet ziet
Wanneer een sync job slaagt, merkt niemand het. Wanneer hij faalt, merkt soms ook niemand het. De job draait, raakt een timeout, logt een error naar een bestand dat niemand monitort, en de twee systemen drijven stilletjes uit elkaar. Inventory in Systeem A zegt 47 toestellen. Inventory in Systeem B zegt 52. Het verschil: vijf toestellen die verwerkt werden tijdens de sync failure. Tegen dat iemand het merkt — meestal omdat een koper vraagt naar een toestel dat in het ene systeem bestaat en in het andere niet — is de data ver genoeg uiteengelopen dat reconciliatie handwerk vraagt.
Handmatige reconciliatie van uiteengelopen systemen is zo'n taak waarvan iedereen het verschrikkelijk vindt en niemand de kost bijhoudt. Het duurt een uur. Of drie uur. Of een volle dag, afhankelijk van hoelang de sync stuk was en hoeveel wijzigingen zich opstapelden. Het is altijd urgent omdat iemand op de data wacht. Het is altijd frustrerend omdat het geen "echt" werk is — het is werk dat ontstaat doordat infrastructuur niet werkte.
Het alternatief
Het alternatief voor sync-gebaseerde integratie is event-gebaseerde integratie: wanneer iets verandert, wordt die wijziging meteen gecommuniceerd. Een toestel wordt verkocht — elk gekoppeld systeem weet het binnen seconden. Een grade wijzigt — de listing toont het onmiddellijk. Een order vertrekt — het klantportaal toont het trackingnummer nog voor de warehouse-operator de scanner heeft neergelegd.
Dit is geen aspiratie. Dit is wat er gebeurt wanneer je systemen een database delen in plaats van data tussen databases te kopiëren. Wanneer het warehouse, de salestool, het klantportaal en de settlement engine allemaal lezen en schrijven op dezelfde source of truth, is er geen sync gap omdat er niets te syncen valt. De data is er al. Ze is altijd actueel. Niemand hoeft te bidden.
Je integratie draait elk uur. In dat uur verandert je warehouse. Je inventory verandert. Je sales pipeline verandert. En je integratie negeert dat trouw allemaal tot de klok zegt dat het tijd is om te kijken. De cron job is geen oplossing. Het is een copingmechanisme voor systemen die eigenlijk altijd één systeem hadden moeten zijn.