Wat is rate limiting? Een begrijpelijke gids voor app-bouwers

Rate limiting is een regel die begrenst hoeveel verzoeken iemand binnen een bepaalde tijd naar een systeem kan sturen — bijvoorbeeld 5 inlogpogingen per minuut, of 100 API-aanroepen per uur. Zodra de limiet is bereikt, worden verdere verzoeken geweigerd (meestal met de foutcode 429 Too Many Requests) totdat het tijdvenster opnieuw begint. Het beschermt apps tegen misbruik, voorkomt dat één zware gebruiker het voor iedereen traag maakt, en stopt uit de hand lopende kosten.

Je komt rate limiting van twee kanten tegen: diensten die jij aanroept beperken jou, en je eigen app moet zijn gebruikers beperken.

Waarom rate limiting ertoe doet bij het bouwen met AI

Apps die met AI zijn gebouwd, zijn vaak verbonden met betaalde diensten — AI-modellen, e-mail, sms, kaarten — en elke aanroep kost geld. Daardoor is rate limiting zowel een beveiligingsfunctie als een budgetfunctie.

• Kostenbeheersing. Als je app een "vraag het aan AI"-vak heeft zonder limiet, kan een bot er 's nachts duizenden verzoeken naartoe sturen. Je betaalt voor elk verzoek.
• Beveiliging. Zonder limiet op het inlogformulier kan een aanvaller duizenden wachtwoorden op een account proberen. Een limiet van enkele pogingen per minuut maakt dat onpraktisch.
• Online blijven. Eén zich misdragend script — soms je eigen code die in een lus vastzit — kan je database overbelasten en de app uit de lucht halen.
• De limieten van andere diensten respecteren. Als je app een externe API te vaak aanroept, krijg jij de 429-fouten, en functies breken voor je gebruikers.

AI-builders bouwen wat je vraagt. Als je limieten niet noemt, worden ze vaak weggelaten.

Een analogie uit het dagelijks leven

Denk aan het gratis bijvulbeleid van een koffietentje: "Eén gratis bijvulling per klant per bezoek."

• Het verhindert niet dat iemand van koffie geniet.
• Het verhindert dat één persoon de hele dag aan de bar staat om een thermoskan voor het hele kantoor te vullen.
• Als iemand een vierde bijvulling vraagt, zegt de barista vriendelijk "niet nu" — dat is de 429.

Een goede rate limit is onzichtbaar voor gewone klanten en valt alleen op bij iemand die iets ongebruikelijks doet.

Hoe rate limiting werkt

Een rate limiter heeft drie onderdelen nodig:

Wanneer er een verzoek binnenkomt, controleert de app de teller voor dat "wie". Onder de limiet: het verzoek gaat door en de teller gaat omhoog. Boven de limiet: het verzoek wordt geweigerd.

Er zijn een paar gangbare manieren om te tellen:

De tellers moeten ergens snel en gedeeld worden opgeslagen. Op één kleine server werkt geheugen. Zodra een app op meerdere machines draait, staat de teller meestal in een gedeelde opslag zoals Redis of de database; anders telt elke machine apart en wordt de echte limiet meerdere keren hoger.

Hoe een beperkte reactie eruitziet

Als een verzoek boven de limiet zit, reageert een goed werkende API met:

• Statuscode 429 Too Many Requests.
• Vaak een Retry-After-header, die aangeeft hoeveel seconden je moet wachten.
• Soms headers die je limiet tonen en hoeveel verzoeken je nog over hebt in dit venster (namen verschillen per provider).

Je app moet op een 429 reageren door te wachten en later opnieuw te proberen — idealiter met exponentiële backoff, wat betekent dat je na elke mislukte poging iets langer wacht (1 seconde, dan 2, dan 4) in plaats van de dienst te bestormen.

Een uitgewerkt voorbeeld: een AI-schrijfassistent

Stel dat je een app hebt gebouwd waarin gebruikers tekst plakken en een AI-herschrijving krijgen.

Zonder limieten: iemand schrijft een script dat 's nachts 20.000 verzoeken verstuurt. De rekening van je AI-provider schiet omhoog, en je account bereikt de eigen rate limit van de provider, zodat echte gebruikers de hele ochtend fouten zien.

Met verstandige limieten:

1. Per ingelogde gebruiker: 30 herschrijvingen per uur op het gratis plan, 300 op betaalde plannen. Boven de limiet ziet de gebruiker: "Je hebt de limiet van dit uur bereikt. Probeer het over 12 minuten opnieuw, of upgrade."
2. Per IP-adres op het aanmeldformulier: 5 aanmeldingen per uur, om te voorkomen dat bots duizenden gratis accounts aanmaken om de limiet per gebruiker te omzeilen.
3. Een uitgavenlimiet ingesteld in het dashboard van je AI-provider, als laatste verdediging als al het andere faalt.
4. Omgaan met de limieten van de provider: als de AI-provider een 429 teruggeeft, wacht je server en probeert één of twee keer opnieuw, en toont dan een vriendelijk "bezet, probeer het opnieuw"-bericht.

De limieten worden op de server gecontroleerd. Een limiet die alleen in de browser bestaat — bijvoorbeeld de knop uitschakelen na 30 klikken — kan worden omzeild door iedereen die je API rechtstreeks aanroept.

Belangrijke termen

Veelvoorkomende misverstanden

• "Rate limiting is alleen voor grote apps." Kleine apps zijn ook doelwit, omdat bots het hele internet afzoeken naar open formulieren en AI-eindpunten. De kosten van misbruik hangen niet af van je omvang.
• "De knop verbergen is genoeg." Limieten aan de browserkant zijn een beleefdheid, geen bescherming. Echte limieten moeten op de server worden afgedwongen.
• "Limieten per IP zijn altijd eerlijk." Veel mensen kunnen één IP-adres delen — een kantoor, een school, een mobiel netwerk. Limieten per gebruiker zijn eerlijker zodra mensen zijn ingelogd.
• "Een 429 betekent dat de dienst kapot is." Het betekent dat je hem te vaak aanroept. Controleer je code op lussen, en cache resultaten die niet vaak veranderen — zie wat caching is.
• "Rate limiting vervangt een uitgavenlimiet." Gebruik beide. Limieten in je app kunnen fouten bevatten; de uitgavenlimiet van de provider is je achtervang.

Wat je aan je AI-builder kunt vragen

• "Voeg rate limiting aan de serverkant toe aan inloggen, aanmelden, wachtwoord resetten en het AI-eindpunt. Stel verstandige limieten voor."
• "Beperk elke ingelogde gebruiker tot [N] AI-verzoeken per uur, en toon een duidelijk bericht met de wachttijd als die limiet wordt bereikt."
• "Wanneer een externe API een 429 teruggeeft, probeer dan opnieuw met exponentiële backoff tot 3 keer, en toon daarna een vriendelijke foutmelding."
• "Waar worden de tellers van de rate limit opgeslagen? Werken ze nog als de app op meer dan één machine draait?"
• "Log elke keer dat een gebruiker of IP-adres een limiet raakt, zodat ik misbruik kan herkennen."
• "Welke externe diensten roept deze app aan, en wat zijn hun rate limits?"

Rate limiting in Mythex

De docs van Mythex zijn hier duidelijk over voor AI-functies: rate limits, veiligheid en kostenbeheersing in apps die je bouwt zijn jouw verantwoordelijkheid om te ontwerpen — zie Een AI-app bouwen. Vraag de agent om limieten toe te voegen in hetzelfde bericht waarin je om de functie vraagt. Op Pro kan een gepubliceerde dienst bij grote drukte op maximaal drie machines draaien (zie Hostinglimieten), dus vraag om tellers die in de database leven in plaats van in het geheugen van één server.

Verder lezen: wat een API is, hoe je LLM-API's gebruikt en de beveiligingschecklist voor met AI gebouwde apps.

Veelgestelde vragen