Rate limiting is een maatregel die begrenst hoeveel verzoeken iemand binnen een bepaald tijdvenster naar je dienst mag sturen, bijvoorbeeld 100 aanroepen per minuut. Zodra die grens wordt overschreden, worden verdere verzoeken beleefd geweigerd tot het venster opnieuw begint. Het beschermt een systeem tegen overbelasting, per ongeluk of met opzet.
Een mooie vergelijking is een drukke club met een portier die telt hoeveel mensen er binnen zijn. De zaak kan een bepaald aantal mensen veilig kwijt, dus zodra het vol is pauzeert de portier de toegang en laat hij mensen door zodra anderen weggaan. Rate limiting doet hetzelfde voor software: het houdt de belasting binnen wat het systeem aankan, zodat één gulzige client de ervaring voor de rest niet verpest. Dat telt vooral voor een API, waar één misdragende koppeling anders duizenden verzoeken per seconde kan afvuren.
Het is ook een eerstelijnsverdediging tegen misbruik: het vertraagt brute-force-inlogpogingen en dempt de impact van een DDoS-aanval, al werkt het het best naast andere maatregelen in plaats van alleen.
Het lastige is het getal kiezen. Zet je de limiet te laag, dan blokkeer je legitieme zware gebruikers of een mobiele app die in pieken synct. Zet je hem te hoog, dan houdt hij bijna niets tegen. Het gangbare antwoord is gelaagde limieten, vaak afgedwongen op een API-gateway: een milde limiet per gebruiker, een strakkere op gevoelige endpoints zoals inloggen, en een ruimere voor de hele dienst. Goede limieten sturen ook een duidelijke retry-header terug, zodat eerlijke clients even kunnen wachten in plaats van te gokken.
Bij TopDevs zetten we verstandige rate limits op elke API en elk inlogeindpunt dat we bouwen, zodat klantsystemen onder druk responsief blijven en de meest voorkomende vormen van geautomatiseerd misbruik weerstaan.
