Je met AI gebouwde app is uitgelicht. Overleeft hij de bezoekerspiek?

Stel je de goede versie van een slechte dag voor. Je plaatste je met AI gebouwde app in een community waar je deel van uitmaakt, of iemand met veel volgers probeerde hem en deelde hem, of hij belandde op de voorpagina van een forum waar je hem niet eens had ingediend. Opeens verandert het straaltje bezoekers waar je aan gewend bent in een vloedgolf. Duizend mensen, allemaal binnen hetzelfde uur aan het rondklikken.

Dit is het moment waarvoor je het ding hebt gebouwd. Het is ook het moment waarop veel met AI gebouwde apps stilletjes omvallen — trage pagina’s, draaiende laadicoontjes, een aanmeldformulier dat niet wil verzenden. De mensen die eindelijk kwamen opdagen lopen tegen een muur en vertrekken, en de meesten komen nooit meer terug om het opnieuw te proberen.

Het goede nieuws: een bezoekerspiek overleven draait grotendeels om een handvol saaie beslissingen die je vóór de piek kunt nemen. Je hoeft geen engineer te zijn. Je moet weten welke hoeken je niet moet afsnijden.

Wat er echt breekt als het verkeer omhoogschiet

Wanneer honderd keer het gebruikelijke aantal mensen je app tegelijk gebruikt, breken dingen niet willekeurig. Ze breken in een voorspelbare volgorde, en het is bijna altijd op dezelfde drie plekken.

De database raakt overbelast. Elke keer dat iemand een pagina laadt, stelt je app meestal een vraag aan zijn database: “wat is de data van deze gebruiker?” Eén persoon die het vraagt, stelt niets voor. Duizend mensen die dezelfde vraag in dezelfde minuut stellen, kunnen zich sneller opstapelen dan de database kan antwoorden, en ieders pagina vertraagt tot een slakkengang.

Iets buiten je app wordt traag. De meeste met AI gebouwde apps leunen op andere diensten — e-mail versturen, betalingen verwerken, een AI-model aanroepen. Die diensten beperken vaak hoe snel je ze mag aanroepen. Bij normaal verkeer merk je de limiet nooit. Tijdens een piek raakt je app hem, en opeens hapert elke actie die die dienst aanraakt.

De app doet keer op keer hetzelfde dure werk. Als je homepage elke keer dat iemand langskomt een zware berekening uitvoert — een lijst ophalen, rangschikken, opmaken — is dat prima voor tien bezoekers en bruut voor duizend. Het werk was altijd al verspilling. Weinig verkeer verborg het alleen.

Let op het patroon: geen van deze zijn nieuwe bugs. De piek heeft niets gebroken. Hij onthulde zwakheden die er al zaten, stilletjes onder weinig verkeer.

De goedkoopste fix: cache de dingen die niet veranderen

Caching klinkt technisch, maar het idee is simpel: als het antwoord op een vraag voor iedereen hetzelfde is en zelden verandert, bereken het dan één keer en hergebruik het in plaats van het werk voor elke bezoeker over te doen.

Je homepage ziet er voor alle 1.000 mensen die hem bezoeken waarschijnlijk identiek uit. Dus waarom de database vragen om hem 1.000 keer opnieuw op te bouwen? Bouw hem één keer, bewaar het resultaat een paar minuten, en serveer die opgeslagen kopie aan iedereen. Je hebt zojuist duizend dure databasetripjes in één veranderd.

Zeg precies dat tegen je AI-bouwer: “Cache de homepage en de openbare productlijst vijf minuten, zodat we niet bij elk bezoek de database raken.” Alles wat voor iedereen hetzelfde is en niet tot op de seconde actueel hoeft te zijn — een prijspagina, een openbare lijst, een blogoverzicht — is een cachekandidaat. De gepersonaliseerde dingen (iemands eigen dashboard, hun accountinstellingen) kunnen niet op dezelfde manier gecachet worden, maar dat is tijdens een piek meestal een klein deel van het verkeer. De meeste mensen kijken naar dezelfde paar openbare pagina’s.

Laat mensen niet wachten op dingen die later kunnen gebeuren

Hier is een fout die makkelijk te maken en makkelijk te repareren is. Stel dat iemand zich aanmeldt en je app hem een welkomstmail stuurt. Als je app hem op de aanmeldpagina laat wachten tot de mail volledig is verzonden, dan maakt een trage e-maildienst je aanmelding traag — op precies het moment dat de meeste mensen zich aanmelden.

De fix is om het trage spul op de achtergrond te laten gebeuren. De persoon ziet meteen “Je bent erbij!” en de mail gaat een paar seconden later de deur uit zonder dat iemand erop wacht. Zelfde uitkomst, maar de bezoeker staart niet naar een laadicoontje terwijl een mailserver drie bedrijven verderop zijn tijd neemt.

Vraag je bouwer: “Stuur de welkomstmail op de achtergrond, zodat de aanmelding er niet op wacht.” Dezelfde logica geldt voor alles wat niet klaar hoeft te zijn voordat de persoon door kan gaan — een rapport genereren, synchroniseren met een ander hulpmiddel, een melding sturen. Als de gebruiker het resultaat niet nu meteen nodig heeft, laat hem er dan niet op wachten.

Heb een “te veel mensen”-plan

Soms is de piek groter dan alles waar je je op had voorbereid, en dan is de eerlijke zet om gracieus te degraderen in plaats van in te storten. Een trage app die nog werkt is beter dan een kapotte.

Een paar simpele versies hiervan:

Een vriendelijk wachtbericht. Als er echt iets overbelast is, is “We krijgen op dit moment veel bezoekers — geef het een momentje” veel beter dan een leeg scherm of een rauwe foutmelding. Mensen vergeven een drukke app. Ze vergeven geen kapotte.
Zet tijdelijk de zwaarste functie uit. Als één functie de dure is — zeg, een AI-generatie die per klik echt geld en tijd kost — kun je hem tijdens een toeloop verbergen en de rest van de app snel houden. De meeste bezoekers tijdens een piek browsen toch, ze gebruiken niet je meest veeleisende functie.
Weet waar je rekening vandaan komt. Als je app bij elk bezoek een betaald AI-model aanroept, kan duizend bezoekers een verrassingsrekening betekenen, niet alleen een trage pagina. Weten welke acties geld kosten, laat je vooraf beslissen wat je begrenst.

Een generale repetitie van dertig minuten

Je hebt geen dure hulpmiddelen nodig om je zwakke plekken te vinden. Je hebt een paar vrienden en een half uur nodig.

Vraag vijf of zes mensen om je app op hetzelfde moment te openen en een paar minuten stevig rond te klikken — aanmelden, de hoofdfunctie gebruiken, de drukke pagina’s laden. Het is grof, maar het brengt het voor de hand liggende spul snel boven. Als de app al traag aanvoelt met zes mensen die erop hameren, plet duizend hem. Als hij vlot blijft, heb je in elk geval de lage lat gehaald.

Terwijl ze klikken, let op welke pagina het traagst aanvoelt. Die trage pagina is precies waar een echte bezoekerspiek het meeste pijn zal doen, en het is het eerste dat het waard is om te cachen of te vereenvoudigen. Je probeert geen duizend gebruikers te simuleren. Je probeert die ene pagina te vinden die bij zes al worstelt.

Het echte doel

Je kunt je app niet oneindig kogelvrij maken, en dat hoeft ook niet. Het doel is niet om bij je eerste virale moment vlekkeloos tienduizend mensen aan te kunnen. Het is om jezelf niet voor schut te zetten voor de paar honderd die eindelijk kwamen opdagen — om ervoor te zorgen dat de mensen waar je zo hard voor hebt gewerkt om ze aan te trekken een werkende app krijgen in plaats van een draaiend wiel.

Cache de pagina’s die niet veranderen. Verplaats het trage spul naar de achtergrond. Heb een plan voor “te veel mensen”. Doe een generale repetitie met vijf vrienden voordat je het nodig hebt. Niets daarvan vereist dat je zelf code schrijft — alleen weten wat je precies aan je AI-bouwer moet vragen.

Dan kun je, wanneer jouw moment komt, ervan genieten in plaats van het in paniek te debuggen. Dus hier is de vraag om deze week bij stil te staan: als er morgen duizend mensen kwamen opdagen, welke pagina zou dan als eerste breken — en weet je dat al?