NS: Reisplanner-appstoring tijdens sneeuwoverlast kwam door ddos-bescherming

De NS Reisplanner was op maandag 5 januari urenlang onbereikbaar vanwege het vele gebruik van de app. Daardoor dacht de Reisplanner-dienst dat er een ddos-aanval was en viel de app ter bescherming uit. Dat zei NS-directeur Wouter Koolmees bij tv-programma Pauw & De Wit.

Vorige week maandag werd de app een recordaantal keer van 28 miljoen gebruikt, zegt Koolmees bij het tv-programma. De laatste piek was 12 miljoen keer tijdens de stakingen van de zomer van 2025. Normaal gesproken wordt de app gemiddeld 2 miljoen keer per dag gebruikt.

Het vele gebruik van de app zorgde ervoor dat de dienst onbereikbaar was. "Dat had te maken met cyberbeveiliging. De app denkt dat die wordt aangevallen en sluit zich af. Dan zit je een paar uur zonder reisinformatie. Dat is onze grootste nachtmerrie, natuurlijk. Onze reizigers staan op het perron en weten niet of ze thuis kunnen komen."

De NS onderzoekt of er bij volgende verwachte drukte flexibeler omgegaan kan worden met de ddos-bescherming. "Of je dan de firewall even los kan laten of iets meer bandbreedte kan geven, omdat er toch reisinformatie beschikbaar moet komen."

De Reisplanner laadde maandag 5 januari urenlang zeer langzaam tot niet. Die dag vielen veel treinen uit vanwege het winterse weer. De NS raadde reizigers daarom aan om kort voor vertrek de app te gebruiken, wat de grote drukte verklaart.

Reacties (145)

[fuzzyIon]

Als een nationale vervoerder struikelt over tientallen miljoenen requests, terwijl commerciële platforms probleemloos miljarden verwerken, dan ligt het probleem niet bij het internet, niet bij de gebruikers en niet bij “de sneeuw”.

Dan ligt het probleem bij:
fragiele architectuur, begrensde bandbreedte en defensieve beveiliging die het systeem niet begrijpt.

En dat is geen natuurverschijnsel. Dat is een keuze.

[david-v]

Als een nationale vervoerder struikelt over tientallen miljoenen requests, terwijl commerciële platforms probleemloos miljarden verwerken

even in de juiste context, je hebt het hier over bijvoorbeeld meta die miljarden requests per dag verwerkt? ofwel een bedrijf dat 164 miljard per jaar winst behaald...versus een nationale vervoerder met een nettoverlies van 141 miljoen in 2024.

Check, nu verder met je verhaal:

Dan ligt het probleem bij:
fragiele architectuur, begrensde bandbreedte en defensieve beveiliging die het systeem niet begrijpt.

Bij gemiddeld 2 miljoen requests per dag, als je dan richting een veertienvoud gaat, ofwel 28 miljoen, dan denk ik dat onze firewall dienst ook in "warmode" gaat. Zeker als je bedenkt dat het vorige record maar een zesvoud was aan dagelijks verkeer.

Fragiele architectuur, niet mee eens, de App kon je openen, website ook, je kreeg netjes te zien dat het nu niet mogelijk was om een reis te plannen.

Begrensde bandbreedte: uiteraard. Je gaat niet betalen voor bandbreedte die je helemaal niet verwacht, ook gezien de historische data. Zie ook het verschil in winst tussen een meta en de NS.

Beveiliging die het systeem niet begrijpt: ik zou zeggen dat het systeem juist heel goed begrijpt dat dit nog nooit eerder is voorgekomen. Leren uit het verleden heet dat. 2x meer keer requests dan de vorige piek is echt enorm veel. Logisch dat het systeem dan denkt aangevallen te worden.

Worden keuzes uit economische redenen genomen? absoluut. Nogmaals, zie de cijfers die ik eerder noemde, groot verschil. Kan dit beter? dat denk ik wel, gezien dit leermoment zou je bij extreem weer mitigerende maatregelen kunnen nemen zoals de DDOS bescherming wat "zachter" zetten mits je backend dat aankan. In dat laatste zit ook een economische uitdaging. Je kan niet zo makkelijk alles zodanig flexibel en schaalbaar maken om zeer extreem gebruik mogelijk te maken. Het heeft een prijs. Zie wederom de cijfers die ik eerder noemde.

Mijn vraag: wil je dit graag wel geregeld hebben door de NS en daar ook de meerprijs per kaartje te betalen? OV is al best wel duur. Nog duurder maken en dan gaan nog meer mensen de weg op, waar je hier geen last van hebt maar wel urenlang in de file zit...

[Reactie gewijzigd door david-v op 13 januari 2026 18:13]

[fuzzyIon]

Je punten zijn terecht, maar ze raken niet helemaal dezelfde laag als waar mijn kritiek zit. Laat me dat onderscheid scherp maken.

Allereerst: ja, de vergelijking met Meta/Google gaat mank als je kijkt naar budget, winst en schaal. Dat was ook niet bedoeld als “NS moet hetzelfde kunnen”. Het punt van die vergelijking is orde van grootte, niet economische gelijkheid. Het internet differentieert verkeer niet op winstgevendheid; architectuur moet omgaan met pieken binnen haar eigen domein.

Dan het verkeer:
Een veertienvoudige piek is groot, zeker. Dat dit de DDoS-bescherming triggert is verklaarbaar. Maar verklaarbaar is niet hetzelfde als wenselijk bij een maatschappelijk kritische dienst. Juist bij extreme omstandigheden (sneeuw, uitval) moet je systeem er rekening mee houden dat gedrag afwijkt van historisch gemiddelde. Dat is geen anomalie, dat is het stress-scenario waarvoor de dienst bestaat.

Over “fragiele architectuur”:
Dat de app en website een melding tonen betekent functioneel dat de UI nog reageert, maar architectonisch dat de kernfunctie (reisplanning) niet gedegradeerd maar volledig geblokkeerd werd. Een robuust ontwerp had minimaal een read-only of gecachte fallback kunnen bieden. Fragiel betekent hier niet “alles plat”, maar “geen gecontroleerde degradatie”.

Begrensde bandbreedte:
Volledig mee eens dat je niet betaalt voor extreme pieken die zelden voorkomen. Maar precies dáár zit het architectuurpunt: je hoeft niet alles op bandbreedte op te lossen. CDN’s, caching, statische noodpaden en gescheiden API-lagen zijn juist bedoeld om zonder structureel hogere kosten pieken op te vangen. Dit is dus niet alleen een geld-vraagstuk, maar ook een ontwerpvraagstuk.

Beveiliging die het systeem niet begrijpt:
Dat het systeem “leert van het verleden” klopt. Maar bij kritische infrastructuur is alleen leren van historische gemiddelden onvoldoende. Context (weer, landelijke verstoringen, tijdstip) hoort mee te wegen. Als legitiem massaal gebruik en een aanval hetzelfde effect hebben, dan is de beveiliging correct vanuit zichzelf, maar niet correct vanuit de dienst.

Dan je laatste vraag — de belangrijkste:

wil je dit graag wel geregeld hebben door de NS en daar ook de meerprijs per kaartje voor betalen?

Eerlijk antwoord: nee, niet per se via hogere kaartprijzen. Dit gaat niet primair over “meer capaciteit kopen”, maar over anders ontwerpen:
– gecontroleerde degradatie
– expliciete crisis-modus
– scheiding tussen kerninformatie en comfortfuncties

Dat hoeft het OV niet structureel duurder te maken, maar vraagt wel bewuste keuzes.

Samengevat:
Ik betwist niet waarom het gebeurde. Dat is goed uitlegbaar.
Ik betwist of dit het juiste faalgedrag is voor een nationale vervoerder op het moment dat mensen de dienst het hardst nodig hebben.

Dat is geen moreel oordeel en geen vergelijking met Meta’s winst, maar een ontwerpvraag.

[david-v]

Het punt van die vergelijking is orde van grootte, niet economische gelijkheid. Het internet differentieert verkeer niet op winstgevendheid; architectuur moet omgaan met pieken binnen haar eigen domein.

Een dienst aanbieden op internet is niet gratis. Je kan een architectuur maken om met 30, 70 of 100x meer verkeer dan verwacht om te gaan, maar ik kan je garanderen dat dat een prijs heeft voor data die niet statisch is en onderhevig is aan wijzigingen zoals de planning van het OV vervoer bij extreem weer.

Ik denk dat iemand hier ook al aanhaalde dat het tonen van bijvoorbeeld statische data waar jij het over hebt

Een robuust ontwerp had minimaal een read-only of gecachte fallback kunnen bieden

Dat is natuurlijk mooi, maar bij uitval van treinen, vertragingen en alternatieve planningen heb je hier weinig aan. Andere data die niet onderhevig is aan wijzigingen zoals de planning werd juist wel getoond. Ofwel wat je hier oppert is gedaan, alleen de planningsdata die onderhevig is aan veel veranderingen werd gestopt.

Zoals in het artikel genoemd, deze piek hebben ze nooit eerder gehad, de vorige was 12 miljoen. Ze hebben misschien wel rekening gehouden met pieken tot 20 miljoen, maar 28 miljoen, dat was dus net teveel.

Ik denk dat de NS wel heeft geleerd van dit probleem en dat er gekeken gaat worden naar de architectuur en de keuzes gebaseerd op deze nieuw record. Maar of dat te doen is zonder extra kosten betwijfel ik...er zal vast wel een kosten/baten analyse gemaakt worden. Hoe vaak komt dergelijk extreem weer nou voor en heb je een fallback?

Wat betreft de fallback, ik had alle informatie die ik nodig had op het station zelf, dus voor mij was het 10 minuten extra reistijd op een reis van 46 minuten zonder storingen. Dat de App niet werkte was vervelend, maar niet meer dan dat.

[fuzzyIon]

Je beschrijving van kosten, historische pieken en pragmatische keuzes klopt. Daar ben ik het grotendeels mee eens. Mijn punt zit alleen op een andere laag dan “hadden ze dit moeten inkopen of niet”.

Dat een dienst op internet geld kost en dat je niet onbeperkt kunt schalen, is evident. Mijn vergelijking ging daarom niet over hoeveel capaciteit NS zou moeten hebben, maar over hoe een systeem zich gedraagt wanneer de capaciteit wél wordt overschreden.

Dat brengt me bij de fallback-discussie. Je hebt gelijk dat bij extreem weer statische planningsdata beperkt nut heeft. Maar precies dát is het architectuurpunt: in stresssituaties is perfecte, actuele planning niet altijd haalbaar, maar volledig wegvallen is ook niet het enige alternatief. Tussen die twee zit een spectrum van gecontroleerde degradatie (bijvoorbeeld: minder detail, tragere updates, beperkte queries per gebruiker, prioritering van basisroutes). Dat is geen gratis capaciteit, maar ook geen volledige herbouw.

Wat betreft “dit was nooit eerder voorgekomen”: dat klopt historisch, maar extreme omstandigheden zijn voor een vervoerder geen exotische randgevallen. Ze zijn zeldzaam, maar voorspelbaar in aard. Architectuur voor kritieke diensten wordt daarom niet alleen ontworpen op gemiddelden, maar op faalgedrag: wat gebeurt er als de grens wél wordt overschreden?

Je persoonlijke ervaring (informatie op het station, beperkte impact) is valide, maar niet universeel. Juist bij landelijke verstoringen zijn er ook reizigers:

• die hun reis nog moeten beginnen
• die geen personeel of borden in de buurt hebben
• die afhankelijk zijn van realtime informatie om alternatieven te kiezen

Voor hen is de Reisplanner niet “comfort”, maar functioneel.

Daarom blijf ik bij mijn kernstelling, licht aangescherpt:
het probleem is niet dat de NS dit had moeten voorkomen tegen elke prijs, maar dat het systeem bij overschrijding van de grens geen gecontroleerd, dienstgericht faalpad had, en in plaats daarvan door een beveiligingslaag werd dichtgetrokken.

Dat is geen beschuldiging en ook geen ontkenning van kostenrealiteit. Het is een constatering over ontwerpkeuzes en prioriteiten. Of en hoe dat wordt aangepast, zal inderdaad via een kosten/batenanalyse lopen — maar die analyse begint pas echt goed als het gewenste faalgedrag expliciet is gedefinieerd.

Dat is waar mijn punt zit.

[GertMenkel]

Laten we alsjeblieft geen OV-geld verspillen door de hele architectuur op te schalen voor het geval er eens in de twee jaar overbelasting plaatsvindt. Natuurlijk kan de NS theoretisch een dozijn FTE's een paar maanden aan extra caching en redundantie besteden maar dat helpt je niet als je reisplannerapp perfect werkt en de trein geannuleerd wordt zodra je instapt. Niemand die denkt "nou, ik moet dan wel een taxi naar huis nemen, maar de error rate van de NS-app is lekker laag".

Al die caching gaat je ook niet helpen als iedere minuut treinen later aankomen, vertrekken, en geannuleerd worden. Het is niet alsof heel Nederland op Amsterdam-Rotterdam zit te zoeken wanneer de app overbelast raakt, eerder "halte kerkstraat - voetbalclub 't balletje". Als je al weet dat je de hoofdverbindingen wil gaan gebruiken, hoef je ook de reisplanner niet religieus te refreshen, die informatie staat ook wel op het bord bij het station.

Het hoofddoel van de NS is niet om een app te maken, maar om de treinen te doen rijden. Als je op het station aankomt en je trein geannuleerd is, is dat kut, maar niet het einde van de wereld. Met de budgetproblemen die de NS al heeft, is het optimaliseren voor een paar dagen sneeuw gewoon onnodig.

[Reactie gewijzigd door GertMenkel op 13 januari 2026 17:06]

[bintang]

Naast budget, winst en schaal is er nog een heel belangrijk verschil: bij Meta/Google is IT de core-business. Als dat niet werkt dan hebben ze geen product. Bij NS is de core-cusiness het rijden van treinen. IT is ondersteunend.

[La1974]

De core business van de NS is het vervoeren van reizigers. Dit kan je tegenwoordig niet zonder IT zien.

De reisplanner is m.i. wel degelijk onderdeel van hun core business. Zowel aan de kant van de planning als de reiziger.

[david-v]

De reisplanner zie ik toch echt als een informatie dienst, met iets meer dan de borden op het station, maar minder dan het antwoord die je van een machinist kan krijgen. Als er geen storingen zijn op het spoor maar de app werkt niet voor het plannen van een rit, dan zal dat nauwelijks merkbaar zijn wat betreft aantal mensen in de trein. Blijkbaar is de App dan geen core business maar een handig informatie kanaal. Zo zie ik het ook. Vervelend, maar zonder kom ik ook thuis.

Donna, het software systeem die de hele planning doet op het spoor zie ik dan weer wel als core onderdeel. Zonder Donna valt het stil. Dat gebeurde ook afgelopen periode.

Vanuit het klant perspectief is alles overigens core business, dus ik snap wel de gedachte. Voor een product owner is elke storing een P1. Mar als je even een stap terug doet en kijkt naar het geheel dan besef je ook wel dat het vooral vervelend was, maar zonder kom je er ook, net zoals vroeger zeg maar, toen je geen apps had

[fuzzyIon]

Ik snap je onderscheid en in operationele zin klopt het:
Donna is core voor het rijden van treinen; zonder Donna staat het systeem stil.
De Reisplanner is een informatiedienst en geen stuurend systeem.

Maar mijn punt zit niet in “kan het spoor rijden zonder de app?” — dat kan uiteraard. Het punt zit in waarvoor de Reisplanner bestaat.

De Reisplanner is namelijk vooral relevant als het níét normaal loopt.
Bij een stabiele dienstregeling is de toegevoegde waarde beperkt; mensen kennen hun traject. Maar bij verstoringen, uitval en alternatief reizen verschuift die informatiedienst functioneel richting operationele ondersteuning van de reiziger.

In die context is “zonder kom je er ook” waar, maar niet volledig:

• je komt er vaak trager
• met meer onzekerheid
• en met minder mogelijkheid om te anticiperen

Dat maakt het geen core operatiesysteem, maar wel een kritisch hulpmiddel in stresssituaties.

Dat is ook waarom de vergelijking met “vroeger zonder apps” maar deels opgaat. Vroeger waren:

• verwachtingen anders
• informatiekanalen eenduidiger (borden, omroep)
• en de complexiteit van het netwerk lager

Tegenwoordig is het systeem complexer, maar is ook de informatielaag een expliciet onderdeel van hoe reizigers hun keuzes maken. Dat verandert de rol van zo’n app, zelfs als hij technisch gezien geen core backend is.

Dus ja:
– Donna is core voor NS-operaties
– de Reisplanner is geen levensader van het spoor

Maar in verstoringen is de Reisplanner meer dan “handig”, juist omdat hij de brug vormt tussen een falend fysiek systeem en menselijke besluitvorming.

Daar zit voor mij het spanningsveld: niet of de app core is, maar hoe het systeem faalt wanneer die informatielaag wegvalt op het moment dat hij het meest nodig is.

Dat maakt het geen drama, maar wel een valide ontwerppunt.

[Bertje3000]

Jij kunt heel goed de exacte schrijfstijl van ChatGPT nadoen zeg

[TheVivaldi]

Plus een ander verschil met Meta: voor Facebook, Instagram, etc. is er vaak geen direct alternatief om aan dezelfde informatie te komen (nieuws kan overal, maar een foto van tante Bep zal ze niet op drie sociale media van andere aanbieders plaatsen). Bij het plannen van een reis zijn er nog andere mogelijkheden dan de NS-app/-site, zoals 9292, OVInfo (weliswaar ietsje onhandiger via OVInfo, maar het is mogelijk), etc. Die twee deden het bij mij uitstekend terwijl NS in storing was.

[david-v]

9292 lag er overigens ook tijdelijk uit, dat was mijn fallback optie en die kon ik toen niet gebruiken. De NS website probeerde ik ook maar die werkte ook niet. Dan maar de borden op het station, die werkten, dus prima fallback.

[morphje]

als je dan richting een veertienvoud gaat, ofwel 28 miljoen, dan denk ik dat onze firewall dienst ook in "warmode" gaat

Nou dat hangt sterk van de applicatie en de aard van de dienst. Stakingen, onderhoud en grootschalige weersevenementen zijn geen vreemden van de NS natuurlijk. Je kan prima de applicatie scaling daar op inregelen en/of voorbereiden.

Dit is net zoiets als de belastingdienst en digid die elk jaar weer met de belastingaangifte verbaasd reageren als de boel overbelast raakt, terwijl het allemaal prima te anticiperen is.

[david-v]

Zeker kan je daar op anticiperen. 2 miljoen gemiddeld, bij zeer grote storingen 12 miljoen. Ik zou dan bijvoorbeeld de 20 miljoen calls per dag wel proberen te halen met de infra. Dit gaat dan weer een stapje verder, 2x meer dan de vorige piek, 28 miljoen calls. Dit is nog nooit voorgekomen.

Wij kunnen op zich ook wel omgaan met pieken met onze systemen, 5x, of 10x meer verkeer, ja, dat kan, onverwacht. Als het gepland druk wordt, denk aan de belastingdienst, dan kan je daar vooraf flink op schalen en zou je nog meer aankunnen.

Zelfs dan zie je dat DigiD en belastingdienst soms bepaalde pieken niet aankunnen. Je kan niet alles eindeloos schalen. Ergens kom je dan een bottleneck tegen. Daar leer je van, mitigeren voor een volgende keer en door. Nu was het bij de NS de firewall die in paniek schoot. Geen idee of de achterliggende systemen de druk aankonden, maar de firewall was in dit geval de bottleneck. Leren en mitigeren voor de volgende keer.

Daarom vind ik het vervelend om te lezen dat mensen dan uitgaan van slecht design, zwakke architectuur en dat ze het zelf wel helemaal goed zouden kunnen doen, enz. Als de NS App om de week eruit ligt zou ik nog wel mee kunnen gaan in de kritiek, maar dit was echt uitzonderlijk, van 12 miljoen naar 28 miljoen calls als record is niet niks.

[Reactie gewijzigd door david-v op 13 januari 2026 18:22]

[n9iels]

Dat is een keuze indeedaad, en volgens mij ook een heel logische en rationele. Ja, je moet rekening houden met piek-momenten in je capaciteit. Maar dit betrof blijkbaar een verbruik dat 14x zo hoog was als normaal. Daarvoor optimaliseren is gekkenwerk. Vergelijk het met zelf altijd 50 pakken koffie in huis hebben omdat misschien de hele straat wel eens langs kan komen in 1x.

[REDSD]

Bijzonder, je geeft men nu wel de mogelijkheid om dus redelijk makkelijk een essentieel onderdeel van je systeem snel plat te leggen.

Je zou er ook voor kunnen kiezen om als het hoofd systeem te veel belast wordt je data statisch nog aanbied als fallback optie, dis is dan misschien iets minder up-to-date (als in een daily van 1-2 minuten misschien?) maar die zou een load van 12 miljoen aanroepen makkelijk moeten aankunnen.

Dus Meneer Koolmees als je mee leest, kijk voor back-ups voor je meest cruciale system, want er zou genoeg mogelijk moeten zijn als je in eenvoud denkt, wat dan niet meteen een paar miljoen kost.

[djwice]

We weten in dit geval 1 ding zeker:

de statische dienstregeling is totaal niet correct

want:

• Veel treinen vallen uit
• Veel treinen rijden op andere tijden
• Veel treinen rijden een andere route dan normaal.

En gezien de complexiteit is het niet mogelijk om elke route elke 2 minuten door te rekenen:
YouTube: NS-dienstregeling wordt met de hand gemaakt!

Wellicht heb jij een nieuw wiskundig algoritme dat dit probleem wel snel kan oplossen? Dat zou een hele uitkomst zijn.

Tot die tijd is schalen met factor 6 voor de grootste piek tot nu toe. En ik begrijp je reactie om niet nog verder op de schalen van wege de kosten, maar de switchen naar static hosting. Dat is dus helaas geen optie.

Voor de gend die willen mee rekening wat schalen kost: nu dus voor het eerst schalen met een factor 14 wat er gevraagd wordt. Er zijn weinig systemen die meer dan 2x boven de hoogste piek ooit gedimensioneerd zijn. De treinkaartjes zouden wel heel wat duurder worden als we dat wel verwachten. Want dat zou betekenen dat je nu factor 33 ten opzichte van normaal verkeer zou moeten reserveren aan hardware. Berekening: 2 is normaal vorige piek 12, nu 28 => 28*28/12 ≈ 65 miljoen requests per dag ~ factor 33 van 2.

[Reactie gewijzigd door djwice op 13 januari 2026 09:22]

[MSalters]

Kul. Het is 2026. Je koopt geen hardware op basis van een piekbelasting. Dit hoort in de cloud. 6x opschalen? Geen enkele cloud partij kijkt daarvan op. 65 miljoen requests per dag? Per uur, dan worden ze misschien een beetje nerveus.

[Robbierut4]

Hoezo "dit hoort in de cloud"?

Bij vrijwel elk artikel waarbij bedrijven overstappen op de cloud is commentaar dat we weer iets van onze zelfstandigheid overhevelen naar grote amerikaanse tech bedrijven.

[Byron010]

Je kan ook prima een nederlandse cloud provider gebruiken toch?

[Robbierut4]

Zoals?

[reinouts]

Zoals Conclusion mission critical? Alleen in de tijd dat ik bij NS zat waren ze wel bezig met alles op Azure zetten.

[samtoxie]

Zie https://european.cloud/, dus bijvoorbeeld https://cyso.cloud/ uit nederland. En je kan natuurlijk ook een hybride strategie toepassen, core draai je on-prem en je benut cloud voor opschalen wanneer nodig.

[Reactie gewijzigd door samtoxie op 13 januari 2026 11:57]

[Navi]

Leaseweb?

[Memori]

Grote partijen (en zelfs concurrenten) die schaalbaarheid nodig hebben maar nog niet in de cloud zitten, kunnen ook hun handen ineenslaan en gezamelijk een nieuwe bedrijf oprichten om zo een goede Europese tegenhanger van Amerikaanse diensten op te richten.

[learn_more]

Maar dat is compleet niet hun core business?

[kodak]

Aangezien clouddiensten niet zomaar aan de gestelde eisen voldoen is dat te simpel. En met het nieuws van de afgelopen jaren over de tekokortkomingen van dit soort dienstverlening mag dan wel een behoorlijke onderbouwing verwacht worden die daar duidelijk rekening mee probeert te houden. Ik lees dat helaas niet in je mening terug.

[kdekker]

Of dit wel of niet in de cloud hoort, lijkt me niet de terechte vraag. Het is aan een bedrijf om te kiezen hoe ze iets doen.

De echte vraag is welke factor je up en down wilt kunnen schalen en wat dat mag kosten. Dat op- en afschelen mogelijk in de cloud makkelijker te realiseren is, is een ander verhaal, maar staat hier m.i. los van. Het is linksom of rechtsom een kostenverhaal (naast architectuur die er geschikt voor moet zijn).

[MSalters]

Geen ervaring met de cloud? Jouw argument over kosten is precies de Unique Selling Point van alle cloud aanbieders. "Makkelijker" is secundair.

[kdekker]

Reageer je om een antwoord te krijgen? Uit je reactie blijkt dat je het antwoord al weet. Dat komt best arrogant over. Kosten is gewoon het belangrijkste punt. En bij de bekende grote externe partijen is niet altijd goedkoper dan alternatieven.

Alleen als je veel procent van de tijd minder dan een compleet systeem nodig hebt, dan komt het wellicht uit. Rack ruimte huren en eigen hardware kan zeker kosteneffectiever zijn, zeker als je bijzondere gebruikspatronen hebt (bijv extreem veel opslagruimte nodig).

Alles in de cloud komt met een prijs. Die USP is gewoon niet altijd aanwezig. En al helemaal niet als jezelf een serieuze systeemruimte hebt (met korting op stroomverbruik en hardware kortingen en een eigen IT-afdeling die al buiten kantooruren kan helpen).

[Reactie gewijzigd door kdekker op 13 januari 2026 22:19]

[supersnathan94]

Mja eens. De NS spulleboel hangt natuurlijk ook gewoon in de Cloud bij MS. Dus dat zou ook gewoon geen enkel probleem moeten zijn. Dat hangen ze niet per se publiek aan de grote klok, maar we weten dat gewoon door dit soort dingetjes:

nieuws: Microsoft lost oorzaak op van Azure-storing die onder meer NS trof - update 2

En uiteraard de vele vacatures voor Azure Devops rollen zoals deze: https://www.werkenbijns.nl/vacatures/azure-cloud-devops-engineer-domein-materieel-onderhoud-utrecht-1253879

Daarnaast ook al zou het wel en probleem moeten zijn, wie heeft dan de DDOS protectie zo gemaakt, dat je eigen klanten deze daadwerkelijk kunnen triggeren? DDOS protectie zou je moeten hebben op een absurd getal wat je naast je daadwerkelijke load hebt, maar dusdanig hoog dat het je onevenredig veel geld gaat kosten en/of echt je infrastructuur plat gaat trekken. Iets meer dan normaal of 3X normaal zou dat niet zomaar moeten zijn toch?

Maar goed. Ze zijn ook actief op zoek naar Java Fullstack Devopsers (whatever that may be) Voor bijvoorbeeld werk aan MAPLE wat het DONNA systeem moet vervangen wat een dag later zorgde voor het vervallen van alle treinen (tot 10:00)

https://www.werkenbijns.nl/vacatures/fullstack-developer-materieel-planning-treindienst-utrecht-1239437

Er wordt wel gewerkt aan vervangingen en updates, maar in de tussentijd zitten we wel met legacy. jammer is dat, want dat betekent gewoon dat er te lang met stilstand wordt "gedealt"

[david-v]

Dit hoort in de cloud. 6x opschalen? Geen enkele cloud partij kijkt daarvan op

gemiddeld 2 miljoen per dag, naar 28 miljoen, ofwel 14x meer aankunnen. Je schaalt niet 1 service maar ws een tiental services. Denk aan firewall, API managers, redis cache, databases, storages, API en ga zo maar door. Opschalen is zeer flexibel in de cloud maar heeft ook grenzen waar je op moet letten. Bijvoorbeeld als er security eisen zijn en je wilt bepaalde services in een vnet plaatsen. Hoeveel services zitten in een dergelijke vnet? hoeveel IP adressen heb je beschikbaar om binnen dat vnet/subnet te schalen?

Databases kunnen ook beperkt worden als je schaalt. Bijvoorbeeld Serverless SQL server in Azure heeft een minimum en maximum aantal cores die je kan instellen. min 1 en max 8 cores, of min 2 en max 16 cores. Je kan dus niet min 1 en max 128 cores nemen, om maar een voorbeeld te geven. Dus als je een te grote broek aantrekt en denkt dat je ooit misschien enorm veel cores nodig gaat hebben, dan betaal je ook enorm veel omdat je min cores ook heel hoog is. Hier moet je heel goed over nadenken.

Bovendien wil je failsafes om te voorkomen dat een DDOS aanval die niet geblokkeerd wordt tot een ware upscaling rage uitmondt waar je de rekening voor krijgt naderhand.

Dit betreft vooral autoscaling. Als je bedrijf groeit en je hebt meer capaciteit nodig dan is de cloud uiteraard heel flexibel en kan je helemaal los gaan, maar dat is planmatig vergroten van je capaciteit, iets totaal anders dan autoscaling a la minute waar we het hier over hebben.

[necessaryevil]

De informatie hoeft ooki niet opnieuw uit een wiskundig model te komen, want die informatie is er al. Sterker nog, je moet gebruik maken van de informatie die er al is, want zo'n model zal meer dan een oplossing hebben. Je wilt de reizigers de oplossing die je gebruikt voorschotelen.

Iets anders: Het is natuufrlijk den beetje raar dat een DDOS-beveiliging er voor zorgt dat de site uitvalt, want dat wil je juist voorkomen met zo'n beveiliging.

[djwice]

Heb je het filmpje bekeken? De informatie is er niet, dat is het hele punt. Treinen rijden in tijd dicht achter elkaar, een vertraging van verschillende treinen kan het hele schema beïnvloeden en dus jouw route planning met overstappen etc.
Het gaat er niet om wanneer de eerst volgende trein op spoor 9 vertrekt, maar hoe je naar dat kleine dorpje komt en of de stoptrein waar je in Bommelerwaard moet overstappen nog wel rijdt vandaag en je niet beter een andere trein moet nemen, en niet via Bommelerwaard moet reizen.

[necessaryevil]

Het ging er even om dat opnieuw berekenen sowieso geen optie is.

[pmeter]

Als de NS app de reisinformatie kan weergeven (als er niet teveel verzoeken tegelijk zijn), dan is ook bij noodweer bij de NS kennelijk bekend wanneer de treinen rijden. Sterker nog. Ik geloof dat de treinen niet rijden als de NS zelf niet weet wanneer ze veilig kunnen rijden. Dus als ze rijden, dan weet de NS globaal wanneer ze het komende uur zullen rijden.

De server die overbelast raakt is de frontend (de webserver) dan wel de server waar de app mee communiceert, beide voor interactieve reisinformatie op maat. Of de backend raakt overbelast door teveel vragen door de frontend.

Als dit systeem overbelast is, lijkt het mij dus goed mogelijk om vanuit de frontend-server door te verwijzen naar een andere frontend-server die op basis van de informatie uit de backend (database) elke 2 minuten een reisschema in de vorm van statische html pagina's genereert. Dat kan fysiek dezelfde server zijn. De backend heeft dan elke 2 minuten maar één gebruiker en dat is de frontend server. En het serveren van statische html pagina's is een veel lichtere workload, zodat de frontend server een veelvoud van gebruikers aan kan. De beveiliging tegen DDOS kan dan een stuk minder strak kan worden afgesteld.

De html pagina's kunnen bijv. een alfabetische lijst met stations zijn. Als je op een station klikt zie je hoe laat in het komende uur (of iets langer) welke trein vertrekt. En misschien ook een lijst met opties voor veelvoorkomende routes.

[Reactie gewijzigd door pmeter op 13 januari 2026 09:53]

[REDSD]

Het feit dat de content statisch is betekend niet dat het oud is. statische content kan gewoon elke minuut bijgewerkt worden, maar zit niet vast aan complexere systemen, zoals authenticatie en database lagen.

Door je systeem process te vereenvoudige en iets minder dynamisch te maken kan je de processen veel stressbestendiger maken zonder voor dure oplossingen te hoeven te kiezen.

[SPee]

Je hebt alleen een front-end systeem nodig dat je horizontaal kunt schalen. Deze kan dan gewoon de aanwezig data cachen en naar de klant sturen. Dit kun je bij elke cloudprovider makkelijk voor elkaar krijgen. Dan schaal je gewoon een paar servers bij voor een paar uur. En met een MessageBus kan een back-end systeem updates naar élk front-end systeem sturen, zonder dat het op de back-end enig impact heeft. Of je gebruikt de tooling die je cloud provider heeft om dit automatisch voor je te doen.

[sdsnatcher73]

Je gaat voorbij aan wat @REDSD voorstelt. De data die nodig is om een dynamisch traject te plannen in de app (voor de eindgebruiker) is er op een gegeven tijdstip. Anders kan de app ook niets. Dus kun je de vertrektijden van de intercity van Amsterdam naar Utrecht van 14:00 (als voorbeeld) op een statische HTML pagina tonen. En deze pagina kun je na elke update van evt. vertraging updaten (dezelfde update moet die app ook hebben). De reiziger die een wat langere reis maakt met overstappen moet dan wat meer werk doen maar het is zeker beter dan helemaal geen informatie beschikbaar hebben.

[djwice]

Oh, dat had ik er niet uit opgemaakt. Het oude spoorboekje, maar dan digitaal met actuele treintijden met een 1 minuut cache policy, zeg maar.

[Reactie gewijzigd door djwice op 13 januari 2026 18:56]

[sdsnatcher73]

Ja zoiets

[blissard]

Was ook het eerste waar ik aan dacht. Bij uitval van de app redirecten naar een ouderwetsche statische HTML pagina met de laatste informatie.

[avlt]

De informatie die ik wil hebben is: hoe kom ik van A naar B en moet ik via C of D reizen?

Hoe stel je je dat voor op een statische pagina?

Alle vertragingen en uitval van alle treinen in heel Nederland op één pagina? En dat up-to-date houden? En doorzoekbaar/logisch gestructureerd?

Volgens mij heb je dan de app nagebouwd zonder routeplanner...

[Robbierut4]

Een statische pagina met vertrektijden vanaf een bepaald station is voor heel veel reizigers al genoeg.

Een groot deel van de reizigers hoeft niet over te stappen. En zelfs die dat wel moeten weten vaak wel waar ze over moeten stappen.

Daar hoeven geen moeilijke berekeningen voor worden gedaan.

[kassius81]

Dat soort statische pagina's bestaan al decennia, je hebt die gele dienstregeling borden die in grote getale op elk station hangen opnieuw uitgevonden!

[Robbierut4]

Daar heb je alleen zo weinig aan als je niet fysiek op het station bent. En in het geval van vertragingen/niet rijdende treinen wil je dat liever weten voordat je naar het station gaat.

Anders kun je de hele app wel afschaffen.

[avlt]

Dan heb je dus een statische pagina voor elk van de ong. 400 stations in Nederland nodig.

En ja, de dagelijkse gebruikers weten waar ze over moeten stappen, maar wat als die trein vandaag niet zover gaat en je een andere route moet kiezen?

Wie gaat dat bijhouden?

[Robbierut4]

Dan heb je dus een statische pagina voor elk van de ong. 400 stations in Nederland nodig.

En ja, de dagelijkse gebruikers weten waar ze over moeten stappen, maar wat als die trein vandaag niet zover gaat en je een andere route moet kiezen?

Wie gaat dat bijhouden?

De app werd 28 miljoen keer gebruikt in 1 dag. Een pagina voor elk van de 400 stations is dus niet echt groot in verhouding.

Daarnaast bestaat het al gewoon. De NS website geeft al de actuele vertrektijden weer op de website: https://www.ns.nl/stationsinformatie/asd/amsterdam-centraal

Het is alleen relatief verstopt op zowel de website als de app.

[The Third Man]

Bijhouden? Het punt is dat je de output automatisch laat genereren (process once) en vervolgens statisch opvraagbaar maakt (serve many). In plaats van bij elk request opnieuw. Behalve dat NS dat al aanbiedt per station, zie hieronder, doet bijvoorbeeld https://www.rijdendetrein...ation/amersfoort-centraal dat ook via de openbare OV API. Het is peanuts om een scriptje te schrijven dat dit automatisch genereert, zeg elke 5 minuten. Alleen je moet het inrichten, dat doen ze niet. Ze leunen in plaats daarvan op het 'app is heilig' paradigma en daardoor is het meteen een kaartenhuis-constructie als diens backend uitvalt.

[djiwie]

Elke 5 minuten is te weinig, je wilt minstens iedere minuut en liever vaker zoiets genereren (zeker voor een druk station). Bij Rijden de Treinen staat de cache op 20 seconden. Verder valide punten hoor.

[Jlaan]

Alleen de info vanaf het station zoals het overzichtsbord wat meestal alleen in de centrale hal zichtbaar is zou je als reiziger heel erg helpen. Dan kun je op het perron bepalen of je naar een ander perron met de sprinter (of juist de IC) gaat of misschien ergens een broodje gaat halen totdat je weer een poging waagt.

[Ryen]

Dus Meneer Koolmees als je mee leest, kijk voor back-ups voor je meest cruciale system, want er zou genoeg mogelijk moeten zijn als je in eenvoud denkt, wat dan niet meteen een paar miljoen kost.

Hoewel de reisplanner -zeker tijdens verstoringen in het treinverkeer- zeer belangrijk is voor de reizigers, is het het niet het meest cruciale systeem. De cruciale systemen zorgen dat de treinen überhaupt (veilig) kunnen rijden.

Verder helemaal met je eens, overigens.

[Randfiguur]

De verkeersleiding verzorgt ProRail.

[roanstrik]

NS heeft ook interne systemen die cruciaal zijn om de treinen te laten rijden, inclusief de interne reisplanners waarmee medewerkers weten waar ze wanneer moeten zijn

[MSalters]

Ook daar is nog verbetering mogelijk. Het is bepaald niet ongebruikelijk dat die systemen uitvallen. De redundantie daar lijkt nogal theoretisch.

[Wasrek]

Maar in dit geval lost een statische pagina het probleem toch juist niet op? Uit het bericht haal ik dat het probleem het aantal verzoeken was, waardoor het leek op een DDOS. Dus niet zozeer dat het te veel verzoeken waren voor genereren van dynamische data. Een statische pagina krijgt nog net zo veel verzoeken dus dat lijkt dan nog steeds op een DDOS toch?

[pmeter]

Een statische pagina is een veel lichtere workload, zodat een server met dezelfde capaciteit een veelvoud aan gebruikers aan kan. Dan kan de beveiliging tegen DDOS ook een stuk minder strak worden afgesteld.

[Finraziel]

Dus... Je 'denied' zelf dan maar vast service om jezelf te beschermen tegen een denial of service aanval? Zelfs als het wel een ddos was, dat klinkt alsof daar toch iets niet kan kloppen...

[Kees]

Ik kan mij voorstellen dat je dat doet om de achterliggende systemen te beschermen. Ik weet niet hoe hun systemen in elkaar zitten, maar ik kan mij voorstellen dat een te hoge load op die systemen ook invloed heeft op hun backend systemen, bijvoorbeeld de informatieborden op de stations.

En dan kiezen ze ervoor om de informatieborden op de stations te beschermen door de app tijdelijk uit te zetten. Het alternatief is namelijk dat zowel die borden als de app nauwelijks werken.

Ik denk ook wel dat ze hiervan leren en zaken aanpassen. Maar dat kost tijd, en met code die teruggaat tot de jaren '90 kan dat soms best ingewikkeld zijn. Niet onmogelijk, maar niet binnen een week opgelost.

Dit is allemaal pure speculatie van mij; maar ik kan mij dit soort systemen wel voorstellen.

[Reactie gewijzigd door Kees op 13 januari 2026 10:28]

[ArmEagle]

Dat lijkt mij een heel slecht ontwerp.

Sowieso is er een centraal systeem. Ik mag aannemen dat die niet door load van app of website wordt geraakt.

Bovendien moeten bijvoorbeeld 9292 en Google ook de data hebben.

[SPee]

NS is redelijk modern en gebruikt ook de cloud voor deze systemen. Ik denk niet dat deze systemen op oude code draaien. Deze zouden in principe opgeschaald kunnen worden, als dat nodig is. En met een cache zou je alle request wel snel kunnen bedienen.

[MSalters]

Ik heb rond 2003 meegewerkt aan het Centraal Reizigers Informatie Systeem (CRIS). Het probleem was niet code uit de jaren 90. Ik geloof direct dat het probleem mensen en procedures uit de jaren 90 zijn. Zo was Prorail er heilig van overtuigd dat er 24 uur in een dag zaten. Elke dag. UTC kregen we daar niet uitgelegd.

[Cristan]

Nou ja, dat kan toch best? Zelf een DDOS bescherming bouwen is bijna niet te doen, dus je neemt een service als die van Cloudflare af. Echter, Cloudflare snapt niet dat bij slecht weer opeens heel Nederland verbinding gaat maken en blokkeert de meeste requests omdat die denkt dat er een DDOS gaande is.

NS is er nu achter gekomen dat dat mis kan gaan en gaan dus kijken of ze Cloudflare anders kunnen configureren / een "slecht-weer modus" kunnen gaan geven.

[nallath]

Je kan bij cloudflare gewoon een vinkje aanzetten dat ie nu even uit moet. Er heeft een dev-ops dus echt zitten slapen.

[Kees]

Behalve dat de NS achter Akamai zit en niet Cloudflare.

[DohnJoe]

en Akamai werkt geheel anders? Hij schreef juist daarom denk ik 'een dienst als Cloudflare', was slechts een voorbeeld.

[gpon]

Binnen een enterpriseomgeving werkt Akamai echt vele malen prettiger dan Cloudflare. Maar dan moet je hem wel goed instellen. Ik gok dat het daaraan mist bij de NS.

[bwerg]

DDOS-bescherming legt niet de hele applicatie plat, het probeert degenen die de DDOS uitvoeren te blokkeren. Met wat kans op geblokkeerde "echte" gebruikers. Als die bescherming denkt dat de DDOS bij wijze van spreken van mensen op Nederlandse stationsperrons afkomt dan worden die geblokkeerd.

Had je de NS-planner vanuit Gambia gebruikt, dan was die misschien gewoon bruikbaar geweest.

Ten minste, dat is een logischere verklaring dan "de app viel uit", zoals Koolmees het verwoordt. Mogelijk is dat gewoon Jip-en-Janneketaal, het is niet alsof er daadwerkelijk gebruikers in Gambia zijn dus effectief komt dat ook op hetzelfde neer.

[Reactie gewijzigd door bwerg op 13 januari 2026 10:05]

[kozue]

Hmm, daar heb je op zich een valide punt. Een DOS bescherming die de hele dienst afsluit is onlogisch. DDOS bescherming zou alleen de aanvallers moeten blokkeren. Alhoewel een DDOS vanaf meerdere locaties komt, zijn er nog steeds een beperkt aantal IP’s bij betrokken, dus die moeten dan afgesloten worden, niet iedereen.
Dus als je thuis op je wifi zit, met een voor jouw huis uniek IP, zul je er geen last van hebben gehad. Maar mensen op 4/5G zitten massaal achter hetzelfde IP via CGNAT. Dus als het inderdaad de DDOS bescherming was, denk ik dat alleen gebruikers op 4/5G of misschien de stationswifi er last van hebben gehad.

[kozue]

Precies. Een dos is juist bedoeld om de service onderuit te halen, dus als je de service plat gooit bij een dos help je de aanvaller juist mee. Dat systeem kunnen ze er beter helemaal tussenuit halen. Iemand daar heeft er niet helemaal goed over nagedacht

[YopY]

Nouja, of wel; bij een DDOS wil je de essentiele functionaliteit in de lucht houden. De conducteurs en medewerkers zullen bijvoorbeeld dezelfde routeplanner gebruiken als klanten (maar technischere details zien). Als de planner overbelast is kun je hem afsluiten voor gebruikers zodat personeel er nog wel bij kan.

Ik werkte voor een energiebedrijf tijdens de energiecrisis van 2022, er kwamen ineens veel meer gebruikers op de site, app, Mijn-omgeving en klantenservice, maar onder water gebruiken ze allemaal dezelfde SAP database. De noodoplossing was om de app en Mijn omgeving dicht te doen zodat de klantenservice en andere core business gewoon door kon gaan.

Natuurlijk is dat een slechte architectuur en zouden het losse / gescheiden databases moeten zijn (readonly database(s) voor klanten enzo), maar daar was nooit prioriteit op gegeven.

[rene_fb]

Natuurlijk is dat een slechte architectuur en zouden het losse / gescheiden databases moeten zijn (readonly database(s) voor klanten enzo), maar daar was nooit prioriteit op gegeven.

Wellicht een onpopulaire mening. Het kan zeker beter, naar ik weet niet of dat echt 'slecht' is.
Zo'n opzet is een relatief slanke en efficiente opzet, welke 99,99% van de tijd perfect werkt.
Nu is het een keer met de app/website misgegegaan, maar de treinen reden (core business) zover mogelijk nog.

Er zal bij de NS nu vast iemand kijken of dit een configuratie-issue was (een te lage threshold was) of date er daaadwerkelijk te weinig rekencapaciteit was om dat aan te kunnen.

Omdat ik 1x per jaar een feest met 30 lui heb, bouw ik ook geen toiletblok met 5 hokjes in mijn huis.

[iam2noob4u]

Ter bescherming doen ze zelf wat precies het doel is van een DDoS. Klinkt een beetje als je eigen arm breken als iemand je bedreigt...

[baseoa]

Oftewel het verhaal klopt niet. Niemand ontwerpt een anti-offline-gehaald-worden-systeem dat zichzelf offline trekt

[ComputerGekkie]

Dat is niet waar. Het anti-offline-gehaald-worden-systeem hoeft niet perse voor alleen de reisplanner te zijn. Het kan ook een automatische maatregel zijn om te voorkomen dat bijvoorbeeld andere software, die primair gebruikt worden voor andere doeleinden offline gaat omdat de app een secundair proces kan meetrekken als het over belast wordt.

Het is een soort noodrem, door het aantrekken kan je dingen slopen en/of beschadigen, maar wordt grotere schade voorkomen.

[baseoa]

Dat zou kunnen maar dat staat er niet en dat zou ook geen anti-DDoS-tooling zijn want het weert de aanval überhaupt niet af. Een maximumsnelheid op de autobaan zou je er dan ook onder moeten schuiven, maar dat vind ik ook geen anti-DDoS ondanks dat het bedoeld is om interne (in dit geval knuffelbare) systemen te beschermen

[Reactie gewijzigd door baseoa op 15 januari 2026 20:57]

[ComputerGekkie]

Tja, de berichtgeving is ook niet voor ons tweakers bedoeld, maar voor de gewone simpele mens :)

[ComputerGekkie]

Het verlicht wel de load op andere secundaire systemen. Wat er weer voor kan zorgen in een “regulier” DDOS scenario dat je nog bij je systemen kan. Als je down gaat door load is het ook lastiger bij je systemen te komen.

[SPee]

Dat kun je ook op andere manier oplossen. Sterker nog; het zou wel vreemd zijn als je hier initieel geen rekening mee houdt. Een cloudomgeving kun je prima up- en downscalen en los van je andere systemen houden.

[ComputerGekkie]

Je reactie lijkt er vooral vanuit te gaan dat dit gaat om een monoliet, daar zou wat je zegt kloppen. Echter, wanneer het een systeem is dat niet makkelijk horizontaal schaalbaar is (en dat kan verschillende redenen hebben) kan dit wel een goede zet zijn geweest om secundaire systemen te beschermen en overige bedrijfsvoering in tact te houden. Wat ik hier vooral uit haal is dat we eigenlijk geen idee hebben hoe het allemaal is ingericht bij de NS, dus het moeilijk is om te stellen dat deze maatregel kul is (of niet).

[scramados]

Vergeet niet dat de NS een commercieel bedrijf is die voor zo min mogelijk geld zo veel mogelijk moet doen.

Als er altijd maar 2 miljoen gebruikers zijn waar zou jij dan in investeren, 1 of 2 extra IT’ers inhuren om dat allemaal mogelijk te maken of een aantal extra conducteurs inhuren. Geld kan helaas maar 1 keer uitgegeven worden.

Ik bouw persoonlijk ook het liefst applicaties 100 keer robuuster dan nodig maar helaas gaat m’n baas dan klagen dat er nog meer te doen is.

[Tc99m]

Vergeet niet dat de NS een commercieel bedrijf is die voor zo min mogelijk geld zo veel mogelijk moet doen.

De NS is een commercieel bedrijf, maar voert een publieke taak uit.

Uiteraard moeten zij (net zoals iedere organisatie, of het nu een bedrijf, non-profit of overheid is) bij iedere euro die ze uitgeven afvragen wat nut en noodzaak is, maar ze kunnen niet bij voorbaat zeggen dat ze bepaalde dingen niet doen omdat ze niet voldoende opleveren.

Als deel van hun publieke taak moeten ze ook gereed zijn voor uitzonderlijke situaties, zoals extreme drukte op hun servers bij veel treinuitval door slecht weer, dan kunnen ze niet standaard de handen er vanaf trekken en zich beroepen op overmacht. Dat is wat Koolmees ook feitelijk zegt: dit had niet moeten gebeuren en moet een volgende keer beter.

[Dream_ON]

[...]

Als deel van hun publieke taak moeten ze ook gereed zijn voor uitzonderlijke situaties, zoals extreme drukte op hun servers bij veel treinuitval door slecht weer, dan kunnen ze niet standaard de handen er vanaf trekken en zich beroepen op overmacht. Dat is wat Koolmees ook feitelijk zegt: dit had niet moeten gebeuren en moet een volgende keer beter.

Dat is dus geheel afhankelijk van hun mandaat die ze van "ons" via de politiek krijgen.
VInde wij dat niet belangrijk genoeg om voor te betalen, dan hoeft de NS dat dus ook niet te doen.

[Zilverdael80]

De app denkt dat die wordt aangevallen en sluit zich af

Hoe komt het dan dat de app toch nog steeds bereikbaar was? Al was het stroperig traag met veel timeouts, maar helemaal afgesloten? Dat lijkt mij toch niet het geval.

Of praten ze hier over een andere 'app'? Beetje onduidelijke context IMO

[croc]

Het zal eerder over de backend gaan, in deze context is API een betere term.

[Milus1972]

Stel je zou alles statisch maken, elke 10 minuten refreshen, of wat haalbaar is, en alles in de browser laten doen. De rekenkracht op backend wordt niet meer live gebruikt, maar alleen om statische pagina's te genereren. Iets robuuster tegen DDoS.

Het ouderwetse papieren spoorboekje gaat uit van routes. Die route moet je zelf uitzoeken. Je kijkt welke vertrektijden er bestaan vanaf je vertrekstation, en stapt dan over op een andere route. Daar moet je voor bladeren. Maar kunnen mensen dat nog wel, zelf door een spoorboekje heenbladeren? Het is geen 1980 meer. Van alles onthouden. Je kunt wel vanuit elk overstapstation + tijd een sprong maken naar andere routes, naar een anker op een andere statische pagina waar je kunt zien wat daar allemaal vertrekt of aankomt.

Maar misschien kunnen we wat meer brute force inzetten. Stel, je wilt voor de komende 24 uur een statisch routeplan laten genereren van elk station naar elk ander station. En er zijn 419 stations in Nederland. Die stations veranderen niet, dus die kunnen per referentie opgehaald. Los daarvan, de meeste mensen kijken hooguit 3 uur vooruit.

Stel je zou voor alle routes een pagina maken. Dan krijg je 419×418=175.142 statische (deel)pagina’s. Dat genereren is misschien niet zwaar, maar het hosten is niet zo handig.

Je kunt ook per station een pagina maken met alle andere stations erin. Dan heb je 419 pagina's nodig met 418 routes naar andere stations met de tijdstippen van de komende 24 uur. Dat is al makkelijker.

Of één HTML‑pagina met een JSON per station en daar clientside doorheen werken. De browser downloadt alleen wat nodig is. Doe je een JSON per station per uur dan wordt het nog kleiner. De NS moet dan per update die 419 JSON's herberekenen en vervangen.

Er moet toch iemand zijn die dat op een zolderkamertje voor elkaar krijgt, voor de sport.

[Reactie gewijzigd door Milus1972 op 13 januari 2026 15:46]

[MSalters]

De eigenlijke planning kan prima in web assembly in de browser. Laat de gebruiker de CPU maar leveren. Backend hoeft alleen de huidige situatie aan te leveren (semi-statisch, update alleen door treinbewegingen).

[Milus1972]

Dat is wel heel actueel. Wat als je in de ochtend voor een reis in de avond wil kijken?

[MSalters]

Nog makkelijker: dat is statische data die een jaar vantevoren al bekend is.

[zonglew00]

Dit klinkt VOOR MIJ als een gevalletje, ik ga geld besparen op iets kritieks omdat het gebeurt toch bijna nooit.

Kennen we dit al? Elke maand de lucht alarm laten afgaan en een persoon dacht we gebruiken dat toch nooit, we gaan switchen op NL-Alert alleen.

Kom op, stuur je personeel op het stationsplein en informeer mensen over de situatie, ja dat staat niet hun in arbeidscontract ivm werkzaamheden en "takenlijst". Dit is een gevalletje "common sense". Dit is niet alleen NS, het hele bedrijfsleven werkt zo. Intern hebben ze vast wel een pagina waar ze live-feed kunnen lezen. Nu moet er waarschijnlijk een complete draaiboek voor inelkaar geschoeft worden en 10 jaar later is de draaiboek weer verouderd.

Stukje "common sense" en gebrek aan improvisatie. Wat als de IT-systeem faalt en dan?

[Reactie gewijzigd door zonglew00 op 13 januari 2026 08:29]

[Dream_ON]

ben jij toevalig op een station gewweest? Of stationsplen? Stonden wel wat meer mensen dan een paar en met komen en gaan van die mensen en allemaal met individuele vragen over hoe in plaats xyz te komen.. Succes met informeren van die mensen. En hoe kom je als mederwerker dan aan de juiste informatie als je systeem plat ligt?

[zonglew00]

Een groot bord op Amsterdam centraal, trains are not departing, if you want to go to the airport take the bus or taxi. Scheelt je een hoop vragen en met een qr code of een wit bord welke treinen er wel rijden.

en ja ik was op station Amsterdam centraal als uber chauffeur. Ik weet niet of jij er was maar ik was er wel. Niet iedereen kent ns.nl en 9292ov.nl met name de niet-Nederlanders. En nu jij.

[Dream_ON]

jazeker, heb zelf maar een uber genomen om thuis te komen ;-)

Borden waren leeg, dus geen treinen. Zo moelijk is het niet. En op elke site buiten NS was het te lezen;, was genoeg info.

[baseoa]

Hè? Dat kan toch niet kloppen. Als je een anti-DDoS-systeem ontwikkelt is het doel toch niet om het voor iedereen plat te leggen..?!

Zulke systemen beogen de niet-legitieme requests eruit te filteren. Dat sommige mensen tijdens zo'n 'elevated traffic level'-situatie de site niet kunnen bereiken is te verklaren, maar dat het zich volledig van de buitenwereld afsluit... dan heeft de aanval zijn doel bereikt en wel dekkender dan de aanvallers op eigen kracht hadden gekund.

Linksom of rechtsom is dit een onvolledig verhaal of volledig verkeerd begrepen door dit bewindslied. Vreemd om het zo klakkeloos overgenomen te lezen

[Reactie gewijzigd door baseoa op 13 januari 2026 09:42]

[CPV]

DDOS voor beginners: als het aantal requests > 5 x het gemiddelde, zal het wel een DDOS aanval zijn.

Geavanceerder kan ook, maar kost meer.

[baseoa]

Per IP misschien, maar dan zou het op gewone dagen ook mensen in de weg moeten zitten die enkele routes na elkaar uitproberen. Het moet niet iedereen eruit knallen op het moment dat zo'n rule getriggerd wordt

[Reactie gewijzigd door baseoa op 13 januari 2026 15:32]

[PaPi36]

De NS heeft het licht overduidelijk niet uitgevonden. Zulke klantonvriendelijke beslissingen worden daar genomen. Als je op het station staat en naar huis moet dan is dat het moment dat de NS moet presteren ook al zijn de weersomstandigheden logisch een uitdaging. Nu laat de app het afweten, doen ze net of treinen over een paar minuten gaan rijden terwijl die dan 2 minuten na gepland vertrek alsnog uitvallen, weten ook personeelsleden niets door de slechte systemen en gokken maar wat. En ondertussen staan honderden te wachten op een trein die wel gaat.