Wat een betrouwbare koppeling echt vraagt

“Knoop X even aan Y” klinkt als een klein verzoek, en het is een van de meest onderschatte soorten werk in software. De verbinding zelf — een API aanroepen, wat velden op elkaar leggen, het resultaat wegschrijven — is meestal een middag werk. Wat de tijd kost, is alles wat er gebeurt als die verbinding zich niet gedraagt.

Concreet, dit bedoel ik.

Webhooks komen vaker dan één keer binnen

Bijna elke leverancier van webhooks zegt ergens in de documentatie dat bezorging “minstens één keer” gebeurt — niet precies één keer. Verbindingen lopen vast, pogingen worden herhaald, en jouw endpoint krijgt dezelfde gebeurtenis twee keer binnen. Als “bestelling betaald” een mail verstuurt of voorraad afboekt, en je vangt dubbele meldingen niet af, dan stuur je vroeg of laat twee mails, of boek je twee keer af. De oplossing is niet ingewikkeld — houd bij welke gebeurtenissen je al verwerkt hebt, zorg dat hetzelfde bericht twee keer verwerken niets extra’s doet — maar het moet er vanaf dag één zijn, niet pas nadat de eerste dubbele in de praktijk opduikt.

Het andere systeem gaat plat terwijl het jouwe draait

Voorraad gelijkhouden tussen een webshop en een planningstool betekent dat een van die twee op enig moment onbereikbaar is terwijl de ander er middenin zit. Wat gebeurt er dan? Als het antwoord is “de synchronisatie mislukt stilletjes en niemand merkt het drie dagen lang”, dan is dat geen theoretisch scenario — dat is wat code standaard doet als alleen het goede pad is uitgewerkt. Een betrouwbare koppeling heeft een plan voor opnieuw proberen, een aparte plek voor berichten die blijven mislukken, en vooral: een manier waarop een mens hoort dat er iets mis is voordat een klant het merkt.

Velden die niet matchen, breken geruisloos

Twee systemen zijn het zelden eens over hoe een “klant” of een “bestelling” eruitziet. De één heeft één veld naam, de ander splitst voor- en achternaam. De één bewaart bedragen in centen, de ander in euro’s met decimalen. Dat soort verschillen geeft geen foutmelding — het levert gewoon verkeerde gegevens op die geloofwaardig ogen, tot iemand ziet dat de totalen niet kloppen. Goed koppelwerk besteedt echte tijd aan die vertaalslag, niet alleen aan het transport.

Wat dat praktisch betekent

Een realistische schatting voor een koppeling ging nooit over “het aanroepen van die API”. Die gaat over: dubbele berichten opvangen, opnieuw proberen met oplopende wachttijd, controleren of de velden kloppen, en bewaking die je vertelt dat er echt iets stuk is in plaats van stil te vallen. Dat is ook waarom kant-en-klare automatiseringstools soms het juiste antwoord zijn en soms niet — ze voldoen prima tot de bovenstaande storingen echt geld gaan kosten, en vanaf dat punt is code die er zelf tegen beschermd is het verschil waard.

Twee systemen die betrouwbaar met elkaar moeten praten, niet alleen uiteindelijk? Laten we het hebben over wat daarvoor nodig is.