In het verleden schreef ik al eens over hoe organisaties verticaal en horizontaal kunnen schalen in het geval van onverwacht succes. Kortom: bij drukte. Vooral bij aanhoudende drukte.
Toch lijkt het erop dat de verkoop van het Nederland Dal Vrij-abonnement de webwinkel van de Nederlandse Spoorwegen tot zijn knieën bracht. Maar hoe kan dat nou? Mogelijk heeft het te maken met een zogeheten single point of failure, en dat is vanuit IT-technisch oogpunt interessant om eens verder te bekijken.
De basis onder de loep
Als we het spoor volgen dan zien we dat ns.nl als domeinnaam al in 1991 door NS werd geregistreerd via Argeweb. Anno 2026 verwijst dit domein naar nameservers van Akamai. Dat zijn nameservers van Akamai Technologies Inc. Akamai wordt algemeen beschouwd als een van de grootste enterprise-CDN's ter wereld.
Dat is doorgaans geen partij die bij 10.000 of 20.000 bezoekers ophoudt met werken. Akamai bedient een groot deel van de grootste websites en bedrijven ter wereld, beschikt over een wereldwijd netwerk van servers en verwerkt dagelijks enorme hoeveelheden internetverkeer. Een piek van enkele tienduizenden bezoekers is op zichzelf dus niet iets waar een partij als Akamai van omvalt.
Op basis van de publiek beschikbare broncode lijkt de NS-webshop te draaien op een eigen frontend-platform met de naam 'Nessie', gecombineerd met een Java/Spring-backend en Thymeleaf-templates. Een groot deel van de statische onderdelen, zoals stylesheets, scripts en lettertypen, wordt daarbij via het wereldwijde CDN van Akamai geleverd. Dat wijst er niet op dat de weblaag zelf de beperkende factor was, maar eerder dat de oorzaak gezocht moet worden in een achterliggend administratief systeem.
Maar wat is er dan gebeurd?
Akamai is een CDN, oftewel een content delivery network. Het slaat afbeeldingen, video's en andere statische onderdelen van een website op. Door slim te routeren weet het deze content op een efficiënte en robuuste manier bij bezoekers af te leveren. In het geval van de NS-website kun je er bovendien vanuit gaan dat een groot deel van het verkeer uit Nederland komt en daardoor grotendeels via Nederlandse of nabijgelegen Akamai-servers wordt afgehandeld.
Maar een webwinkel die abonnementen verkoopt is méér dan alleen een verzameling statische bestanden. Er zit ook een administratieve laag achter. Zo moet er bij elk verkocht abonnement voor worden gezorgd dat dit abonnement actief wordt gemaakt op het OV-chipkaartnummer en/of OVpay-account van de koper. En daar zit mijns inziens vermoedelijk de bottleneck die alles de das omdeed: de zwakste schakel, zogezegd.
Stel dat er bij de verkoop van een Nederland Dal Vrij-abonnement een API-aanroep gedaan moet worden naar een systeem van Trans Link Systems (TLS) om het abonnement aan een reiziger te koppelen. Dan ontstaat er één administratief systeem dat bij iedere verkoop een stukje werk moet verrichten. Als zo'n API-systeem niet berekend is op enkele tienduizenden handelingen in korte tijd, dan kan alles vastlopen.
Ik benadruk overigens dat dit een technische hypothese is. Ik weet niet hoe de systemen van NS en TLS daadwerkelijk zijn ingericht. Maar in de praktijk zie je dit soort afhankelijkheden vaker terug bij plotselinge piekbelasting.
Hoe kun je zoiets voorkomen?
Problemen zoals deze zijn niet nieuw. Partijen die concertkaartjes verkopen hebben hier ook regelmatig mee te maken. Het verkeer op hun website is doorgaans slechts een fractie van het verkeer dat ineens ontstaat zodra de kaartverkoop voor een populair concert opent. Het kan zomaar gebeuren dat er binnen een uur 50.000 bezoekers tegelijkertijd een kaartje proberen te kopen.
Aan de andere kant kun je als NS of concertkaartjesverkoper niet iedere dag de zwaarste en duurste infrastructuur paraat hebben staan. Dat zou onnodig veel kosten met zich meebrengen. Je wilt dus eigenlijk alleen extra capaciteit inzetten op piekmomenten. Die momenten kun je vaak zien aankomen en met moderne technieken kunnen ze zelfs automatisch worden gedetecteerd, waarna systemen automatisch kunnen opschalen.
Maar nogmaals: in dit geval lijkt het probleem niet bij de website of webshop zelf te hebben gelegen. Vermoedelijk zat de beperking in een achterliggende administratieve API. En juist dáár had de schaling moeten plaatsvinden.
Uitstellen en verdelen
Er is overigens nog een derde mogelijkheid: uitstellen. De infrastructuur van NS had bij de aanschaf van een abonnement simpelweg kunnen registreren welke reiziger het abonnement had gekocht en die gegevens in een eigen database kunnen opslaan. Vervolgens had een achtergrondproces, bijvoorbeeld via batches (een wachtrij), ervoor kunnen zorgen dat er maximaal een bepaald aantal verzoeken per uur naar de TLS-API werd verstuurd. Op die manier hoeft de API zelf niet direct mee te schalen en wordt de druk uitgesmeerd over een langere periode.
Het enige nadeel is dat deze abonnementen niet alleen vanaf 15 juni verkocht werden, maar ook direct vanaf 15 juni gebruikt konden worden. Idealiter was de verkoop eerder gestart, zodat er voldoende tijd was om die administratieve verwerking geleidelijk uit te voeren. Bij een vertraagde verwerking bestaat immers de kans dat een deel van de ruim 31.000 verkochte abonnementen pas later die dag actief zou zijn geworden.