De koppeling is gebouwd, getest en live gegaan. Orders uit de webshop komen binnen in Salesforce, facturen worden automatisch gegenereerd, klantdata synchroniseert tussen CRM en ERP. Zes maanden later werkt alles nog steeds. Een jaar later ook.
En dan groeit het volume. Het bedrijf groeit, het aantal transacties neemt toe, nieuwe vestigingen worden toegevoegd, een acquisitie brengt extra datasystemen mee. En dan begint de koppeling te stotteren. Vertraging in datasynchronisatie, mislukte berichten die stil verdwijnen, dubbele records die plotseling opduiken, een integratie die bij piekbelasting vastloopt.
Wat bij klein volume prima werkte, schaalt niet. En dat is zelden toeval.
De meest voorkomende oorzaken
In de integraties waarbij ik word gevraagd te kijken waarom het mis gaat, kom ik een handvol patronen steeds opnieuw tegen.
Geen foutafhandeling buiten de happy path. De koppeling is gebouwd voor de situatie waarbij alles goed gaat. Maar als een externe API traag reageert, een record niet gevonden wordt, of een veld een onverwachte waarde bevat, is er geen goede afhandeling. Het bericht verdwijnt stil, het systeem crasht, of er wordt een gebrekkige fallback uitgevoerd. In testomgevingen komt dit nooit naar boven. In productie, onder druk, wel.
Synchrone koppelingen die eigenlijk asynchroon moeten zijn. Een koppeling die op elk verzoek wacht totdat de andere kant antwoordt, werkt prima bij lage volumes. Maar bij hogere volumes stapelt het wachten zich op: systemen worden traag, time-outs nemen toe, gebruikers klagen. Asynchroon ontwerp met een berichtenwachtrij is bij hogere volumes robuuster, maar het vereist meer aandacht bij het ontwerp.
Geen idempotentie. Wanneer hetzelfde bericht meerdere keren wordt afgeleverd, wat bij foutafhandeling en retries onvermijdelijk is, moet het systeem dat aankunnen zonder dubbele records aan te maken of acties dubbel uit te voeren. Een integratie zonder idempotentie leidt bij grotere volumes tot datavervuiling die handmatig moet worden opgeschoond.
Hardgecodeerde limieten en identifiers. Een koppeling die werkt met vaste ID’s, vaste accountnummers of vaste URL’s die direct in de code staan, is moeilijk aan te passen wanneer de situatie verandert. Dat leidt tot fragiele koppelingen die bij elke wijziging handmatige interventie vragen.
Het probleem met testen op laag volume
Veel integratiefouten komen niet naar voren in de testfase, simpelweg omdat er op laag volume wordt getest. Vijf testbestellingen lopen soepel. De koppeling is goedgekeurd. Maar bij honderd bestellingen per uur, met variatie in dataformaten, uitzonderingen en piekbelasting, gedraagt een koppeling zich anders.
Loadtesting is geen overbodige luxe voor integraties die in productie onder variabele belasting staan. Het is een basisvereiste. Hetzelfde geldt voor een minimale chaostest: wat gebeurt er als de externe API een minuut niet beschikbaar is? Wat als een veld leeg is dat normaal altijd gevuld is?
Monitoring als vereiste, niet als optie
Een integratie zonder monitoring is een black box. Je weet niet of berichten aankomen, hoe lang verwerking duurt, of er fouten zijn die stil worden afgehandeld. In kleine volumes is dat beheersbaar: als er iets mis is, hoor je het snel van een gebruiker.
Bij grotere volumes is dat niet langer werkbaar. Fouten stapelen zich op voordat iemand ze merkt. Monitoring die actief alarmeert bij mislukte berichten, ongewone verwerkingstijden of afwijkende recordaantallen, maakt het verschil tussen een beheerste omgeving en een reactieve brandweer.
Wanneer herbouwen?
Er is een punt waarop een koppeling zoveel technische schuld heeft opgebouwd dat repareren minder efficiënt is dan herbouwen. Dat punt is moeilijk te erkennen, zeker als de oorspronkelijke bouwers nog bij het project betrokken zijn.
Indicatoren zijn: steeds terugkerende fouten die tijdelijk worden opgelost maar niet structureel, onderhoudstijd die een groot deel van de beschikbare capaciteit opslokt, of de onmogelijkheid om de koppeling eenvoudig uit te breiden zonder risico voor de bestaande werking. Herbouwen is geen falen. Het is erkennen dat de initiële opzet is ontworpen voor een situatie die niet langer de huidige is.
Conclusie
Integraties worden gebouwd voor de situatie van vandaag. De fouten die ze later in de problemen brengen, zijn niet slordig, ze zijn logisch: niemand weet vooraf exact hoe snel een organisatie groeit en welke eisen er over drie jaar aan een koppeling worden gesteld.
Wat je wel kunt doen, is bij het ontwerp bewust kiezen voor robuustheid: foutafhandeling die werkt buiten de happy path, asynchroon design waar volume dat vraagt, monitoring die actief informeert en idempotentie die dubbele verwerking voorkomt. Dat zijn geen gold plating-keuzes. Het zijn investeringen die de levensduur en betrouwbaarheid van een koppeling substantieel verlengen.
Loopt jouw integratie tegen zijn grenzen aan? Blazeforce helpt bij het beoordelen van bestaande koppelingen en het herbouwen op een robuust fundament. Neem contact op voor een vrijblijvend gesprek.