Vrijwel elke applicatie praat met andere systemen: betalingen, boekhouding, CRM of een kaartdienst. Elke koppeling is een afhankelijkheid die je niet zelf in de hand hebt. De vraag is niet óf een externe dienst een keer faalt, maar wat er dan gebeurt.
Ga uit van falen
Een netwerkverzoek kan mislukken, traag zijn of een onverwacht antwoord geven. Ontwerp elke koppeling alsof dat vandaag gebeurt.
Retries met beleid
Opnieuw proberen helpt bij tijdelijke storingen, maar alleen met beleid. Wacht steeds iets langer tussen pogingen (exponential backoff) en stop na een vast aantal pogingen.
Idempotentie
Als een verzoek twee keer aankomt, mag het resultaat niet dubbel zijn. Stuur daarom een unieke sleutel mee, bijvoorbeeld een Idempotency-Key, zodat de ontvanger dubbele verzoeken herkent.
Timeouts
Zonder timeout kan één trage dienst je hele applicatie laten wachten. Stel altijd een bewuste maximale wachttijd in.
Asynchroon waar het kan
Niet alles hoeft direct. Door werk in een wachtrij te zetten en op de achtergrond te verwerken, merkt de gebruiker niets van een trage of tijdelijk onbereikbare dienst.
Contracten bewaken
Leveranciers passen hun API soms aan. Met contracttesten controleer je automatisch of het antwoord nog de vorm heeft die jouw code verwacht.
Zichtbaarheid
Log elke mislukte koppeling met genoeg context om hem te kunnen herhalen. Een overzicht van mislukte berichten, met een knop om ze opnieuw te verwerken, voorkomt veel handwerk.
Conclusie
Robuuste koppelingen ontstaan door falen serieus te nemen: retries met beleid, idempotente verzoeken, timeouts, asynchrone verwerking en goed zicht op wat er misgaat.
Geschreven door
Mustafa
Ik ontwerp, ontwikkel en verbeter digitale oplossingen — voor jouw bedrijf.