Hur en rate limit avgör om din förfrågan går igenom
En rate limit begränsar antalet förfrågningar en klient får skicka inom ett visst tidsfönster och returnerar 429 när gränsen överskrids. Gränsen finns för att förhindra att en klient förbrukar kapacitet som tillhör alla, vilket är anledningen till att det korrekta svaret är att sakta ner snarare än att skicka samma förfrågan igen omedelbart.
Att försöka igen omedelbart är precis vad de flesta första integrationer gör, och det förvandlar ett tillfälligt avslag till ett ihållande sådant. Klienten når gränsen, försöker igen, förlänger tidsfönstret den mäts över och blir strypt mycket längre än vad den ursprungliga burst-belastningen krävde, oftast medan en utvecklare drar slutsatsen att API:et är opålitligt. Din egen limitkonfiguration – tröskelvärden per nivå, burst-gränser och slutpunkter med snävare gränser – är medvetet exkluderad här, då den hör hemma i versionshanterad dokumentation snarare än i en video som åldras.
Mallen följer en förfrågan genom åtta scener: en om varför gränser överhuvudtaget existerar, en om tidsfönstret och hur det räknas, en om vad ett 429-svar innehåller, två om backoff och varför fördröjningen måste öka, en om jitter och 'thundering herd'-problemet, en om att läsa rate limit-headers, och en om att designa så att gränsen sällan nås.
.PNG)
.PNG)
.PNG)
