Vraag een engineer van hoeveel externe diensten hun systeem afhankelijk is en u krijgt meestal een getal. Vraag om ze allemaal op te noemen, en het getal groeit terwijl ze praten.
Een modern bedrijfssysteem is niet één stuk software. Het is een betaalprovider, een e-mail-API, een adresvalidatiedienst, een ERP-connector, een identityprovider, een CDN, een cloudregio, een DNS-resolver en een handvol kleinere API’s die iemand jaren geleden voor een specifieke behoefte integreerde. Elk daarvan werkt bijna altijd. Geen enkele is van u.
Dat is de realiteit waarvoor u zou moeten ontwerpen, en de meeste processen zijn daar helemaal niet op ontworpen.
Het proces dat iedereen ontwerpt
Loop door de specificatie van een typisch order-, claim- of onboardingproces en u vindt een nette volgorde: de klant dient in, het adres wordt gevalideerd, de betaling wordt geautoriseerd, het record wordt in het ERP aangemaakt, de bevestigingsmail gaat uit, het document wordt gearchiveerd.
Elke stap gaat ervan uit dat de vorige slaagde. Elke externe aanroep gaat ervan uit dat de provider antwoordt. Het ontwerp beschrijft wat er gebeurt als alles werkt, omdat iedereen het daarover eens kan worden, en omdat het alternatief ongemakkelijke vragen oproept over wie verantwoordelijk is als dat niet zo is.
De impliciete aanname is dat die providers feitelijk deel uitmaken van uw systeem: altijd beschikbaar, altijd hetzelfde, nooit fout. Dat zijn ze niet. Het zijn zelfstandige bedrijven met eigen deploys, eigen incidenten en eigen slechte dinsdagen.
Wat er werkelijk gebeurt
De cijfers zijn niet dubbelzinnig. Tussen augustus 2024 en augustus 2025 registreerden AWS, Azure en Google Cloud samen meer dan honderd storingen. Ongeveer 94% van de zakelijke diensten wereldwijd leunt op minstens één grote cloudprovider, en de drie grootste beheersen ruwweg 62% van de markt. Concentratie is efficiënt, tot ze dat niet meer is.
De afzonderlijke incidenten zijn leerzaam, want geen enkele was exotisch:
- In oktober 2025 legde een DNS-resolutiefout in één AWS-regio diensten urenlang plat, met gevolgen voor meer dan 3.500 bedrijven in 60 landen. De aanleiding: een leeg DNS-record en een automatiseringsupdate.
- In november 2025 verspreidde een groter dan verwacht bestand in het Bot Management-systeem van Cloudflare zich binnen enkele minuten wereldwijd, met verslechterde dienstverlening voor een groot deel van de 2,4 miljard gebruikers wier verkeer via dat netwerk loopt. Geschatte kosten: meer dan 250 miljoen dollar.
- In juli 2024 liet een foutieve update van een securityagent Windows-hosts wereldwijd crashen. Het was helemaal geen cloudstoring, en analisten schatten de schade voor alleen al de Fortune 500 op 5,4 miljard dollar.
- In mei 2026 maakten ongeldige DNSSEC-handtekeningen voor de .de-zone domeinen onbereikbaar op het internet, inclusief tweedelijnsdomeinen die zelf geen DNSSEC gebruikten.
Die laatste verdient een tweede lezing. Bedrijven gingen offline door een afhankelijkheid die ze nooit hadden geconfigureerd, nooit hadden gekozen en waarschijnlijk nooit hadden opgesomd. Zo ziet het probleem eruit: de afhankelijkheden die pijn doen zijn zelden degene die u in de gaten houdt.
Nog één detail is het weten waard. Analyse van recente grote incidenten vond dat ruwweg een kwart van de totale impacttijd voor klanten verstreek voordat de provider zelf wist wat er kapot was. Wachten tot de statuspagina u vertelt wat er aan de hand is, is geen herstelstrategie.
Als het proces stopt, stopt er nog iets
Hier wordt dit een bedrijfsgesprek in plaats van een technisch gesprek.
Als een externe aanroep faalt en het proces stilvalt, hangt het gevolg volledig af van wat dat proces doet. Een trage marketingpagina is vervelend. Een orderstraat die geen orders kan aannemen is omzetverlies, en dat komt later niet terug. Een logistiek systeem dat geen verzendlabels kan maken zet vrachtwagens stil. Een facturatierun die op de laatste dag van de maand niet afkomt, wordt een cashflowprobleem en een afstemmingsprobleem. In gereguleerde contexten kan een gestopt proces een meldplicht worden.
De belangrijke vraag is niet “hoe betrouwbaar is deze provider”. Ze luidt: als deze provider vier uur onbeschikbaar is, wat valt er dan stil, en wat kost ons dat?
De meeste bedrijven hebben die vraag nooit per afhankelijkheid gesteld. Ze hebben een algemeen gevoel dat een storing vervelend zou zijn, en dat is niet specifiek genoeg om tegen te ontwerpen.
Hoe een veerkrachtig ontwerp er werkelijk uitziet
Veerkracht gaat niet over perfecte beschikbaarheid, die u voor geen prijs kunt kopen als de storing stroomopwaarts zit. Ze gaat erover dat een leveranciersstoring uw proces laat degraderen in plaats van stoppen.
Een paar patronen doen het meeste werk.
Ken de volledige afhankelijkheidskaart
U kunt niet ontwerpen rond wat u niet in kaart heeft. Dat betekent elke externe aanroep, ook de aanroepen die verstopt zitten in een library, geërfd zijn van een leveranciersmodule of jaren geleden zijn toegevoegd door iemand die inmiddels vertrokken is. Het betekent ook de afhankelijkheden onder uw afhankelijkheden: de regio, de DNS, het CDN, de identityprovider.
Die inventarisatie is de onopvallende eerste stap, en daar komen de meeste verrassingen boven.
Bepaal per afhankelijkheid wat falen moet doen
Niet elke afhankelijkheid verdient dezelfde behandeling. Per stuk zijn er maar een paar zinnige antwoorden:
- Laat de transactie falen, wanneer doorgaan zonder die stap verkeerd zou zijn. Een betalingsautorisatie mag u niet aannemen.
- Degradeer netjes, wanneer de stap verrijkend is in plaats van essentieel. Ligt adresvalidatie eruit, accepteer het adres dan en markeer het voor controle in plaats van de order te blokkeren.
- Zet in de wachtrij en probeer opnieuw, wanneer de stap later kan gebeuren zonder schade. Bevestigingsmails en synchronisaties hoeven zelden synchroon te zijn, en ze zo behandelen verandert een hik bij de provider in een zichtbare fout voor de klant.
- Schakel over naar een alternatief, wanneer de functie echt kritiek is en er een tweede provider bestaat. Dit is de duurste optie, en dus een bewuste keuze voor een klein aantal afhankelijkheden in plaats van een ambitie voor allemaal.
Het punt is dat elk van deze een bedrijfsbeslissing is die in code wordt uitgedrukt. Iemand moet beslissen of een order geaccepteerd moet worden wanneer een niet-essentiële controle onbeschikbaar is. Engineering kan beide antwoorden implementeren, maar zou niet degene moeten zijn die gokt.
Beperk de storing
Timeouts, circuit breakers en bulkheads bestaan zodat een trage provider geen gestopt systeem wordt. Zonder timeout houdt een hangende externe aanroep een verbinding vast, dan een thread, dan de pool, en legt één verslechterde integratie een applicatie plat die nog veel meer te doen had. Een verrassend deel van de volledige storingen begint als één trage afhankelijkheid.
Maak de wachtrij standaard voor alles wat asynchroon kan
Hoeft een stap niet af te ronden voordat de gebruiker antwoord krijgt, dan hoort die niet in het kritieke pad. Achter een duurzame wachtrij zetten betekent dat een storing werk vertraagt in plaats van verliest, en het proces loopt vanzelf bij wanneer de provider terug is.
Oefen het
Een fallbackpad dat nooit is uitgevoerd, is een hypothese. De goedkoopste nuttige test is een afhankelijkheid uitschakelen in een testomgeving en kijken wat het proces doet. De antwoorden zijn vaak ongemakkelijk, en precies daarom is de oefening de moeite waard voordat de provider de datum voor u kiest.
Dit is een ontwerpvraag, geen inkoopvraag
Het is verleidelijk leveranciersrisico in contracten te willen oplossen. SLA’s en tegoeden doen ertoe, maar ze compenseren u achteraf. Ze houden geen orders draaiend op de ochtend dat ergens buiten uw controle een DNS-record misgaat.
Wat het proces draaiend houdt, is een ontwerp dat de storing voorzag. En dat ontwerp is alleen mogelijk als iemand het proces van begin tot eind begrijpt: niet alleen de code, maar waar elke stap voor dient, zonder welke stappen het bedrijf echt niet verder kan, en hoe een acceptabele gedegradeerde modus eruitziet.
Dat totaalbeeld is wat we opleveren in een technology assessment, en wat we in stand houden wanneer we een systeem overnemen. Het is ook waarom we blijven benadrukken dat documentatie geen administratieve franje is: u kunt geen veerkracht ontwerpen in een proces dat niemand volledig kan beschrijven.
Perfecte beschikbaarheid is niet te koop. Een proces dat zijn leveranciers overleeft wel.
Veelgestelde vragen
Wat is systeemveerkracht in een bedrijfscontext?
Veerkracht is het vermogen van een bedrijfsproces om door te draaien wanneer delen ervan falen, vooral delen die u niet beheert. Het is niet hetzelfde als beschikbaarheid. Een veerkrachtig ontwerp accepteert dat externe providers zullen falen en zorgt dat het proces degradeert, in de wachtrij zet of omleidt in plaats van stopt.
Waarom raken storingen bij providers als AWS of Cloudflare ons, als we geen directe klant zijn?
Omdat afhankelijkheden gelaagd zijn. Uw provider draait mogelijk op een cloudregio, achter een CDN, met een DNS-resolver of identitydienst die u nooit koos. In mei 2026 maakten ongeldige DNSSEC-handtekeningen op de .de-zone domeinen onbereikbaar, zelfs voor organisaties die zelf geen DNSSEC hadden ingeschakeld. De afhankelijkheidskaart is meestal dieper dan de contractenlijst.
Hebben we voor alles een tweede provider nodig?
Nee, en het proberen is meestal een slechte investering. Redundantie is duur in bouwtijd en in doorlopend onderhoud. De bruikbare aanpak is per afhankelijkheid beslissen: falen, degraderen, in de wachtrij zetten, of overschakelen. Volledige redundantie loont alleen voor de enkele afhankelijkheden waar het proces echt niet mag stoppen.
Hoe vinden we uit waar ons werkelijke risico zit?
Breng elke externe afhankelijkheid in kaart, ook de indirecte, en stel per stuk één vraag: als dit vier uur onbeschikbaar is, wat valt er stil en wat kost dat. Dat verandert een vage angst voor storingen in een korte, geprioriteerde lijst van dingen waar het loont omheen te ontwerpen.
Is dit iets wat we één keer oplossen?
Nee. Afhankelijkheden veranderen naarmate integraties worden toegevoegd, leveranciers hun voorwaarden wijzigen en providers diensten uitfaseren. Veerkracht is een eigenschap van een systeem dat wordt onderhouden, geen project dat afloopt.
Weet u niet zeker waar uw systemen werkelijk van afhangen, of wat er zou stilvallen als een provider morgen uitvalt? Begin met een technology assessment met vaste scope, of neem contact op.