Rate limits, 429's en tier-upgrades
Bijgewerkt September 1, 2026 · eerst gepubliceerd September 1, 2026
Als een dienst 429's begint terug te geven, is de reflex het als een beschikbaarheidsincident te behandelen: de limiet verhogen, de tier upgraden, retries toevoegen, de doorvoer herstellen. Soms is dat juist. Het is ook het mechanisme waarmee een op hol geslagen loop een rekening van vijf cijfers wordt, omdat het enige dat hem tegenhield zojuist is weggehaald.
Wat een 429 je eigenlijk vertelt
Het zegt dat het systeem sneller probeert uit te geven dan zijn budget toelaat. Dat gebeurt om twee heel verschillende redenen, en die vragen om tegengestelde reacties. Echte vraaggroei — meer gebruikers, een lancering, een seizoenspiek — betekent dat de limiet echt te laag is en dat verhogen echte omzet oplevert. Op hol geslagen gedrag — een retry-storm, een agent die in een loop zit, een backfill die niemand heeft gethrottled, een testsuite die op productiesleutels wijst — betekent dat de limiet precies doet waarvoor hij bedoeld is.
De twee zijn aan het foutpercentage alleen niet te onderscheiden. Aan de kosten per werkeenheid zijn ze triviaal te onderscheiden: echte groei houdt de verhouding ruwweg constant terwijl het volume stijgt; een op hol geslagen proces breekt haar, met veel hogere uitgaven per voltooide taak dan gisteren. Die ene verhouding zou elke tier-upgrade moeten bewaken.
Retries maken het stilletjes erger
Naïef opnieuw proberen bij een 429 zonder exponentiële backoff en jitter verandert één overschrijding van de limiet in een gesynchroniseerde storm. De verzoeken die slagen worden gefactureerd; veel van de verzoeken die falen hebben toch al inputverwerking verbruikt. En omdat retries meestal in een clientbibliotheek zijn geïmplementeerd en niet in applicatiecode, komt de versterking nergens in de ontwerpdocumenten van de feature voor.
Gebruik limieten bewust
Stel je eigen limieten lager in dan die van de provider, per omgeving en per feature, zodat het eerste dat breekt van jou is en jij bepaalt wat er daarna gebeurt. Houd niet-productie strikt begrensd — een mislukte testbuild is goedkoop, een afgekapt klantpad niet. Alarmeer op de verhouding kosten per taak, niet alleen op foutaantallen. En als je een tier upgradet, behandel dat dan als een uitgavenbeslissing met een benoemde eigenaar, want dat is het.
Gerelateerd
Gerelateerd
Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit →