Rate limiting

Rate limiting er en kontrol, der begrænser, hvor mange anmodninger eller handlinger en klient må udføre inden for et bestemt tidsrum. Trafikken tælles mod en nøgle, eksempelvis en bruger, tenant, API-nøgle eller operation.

En politik kan både angive en vedvarende hastighed og en tilladt kortvarig spidsbelastning, også kaldet et burst. Når grænsen overskrides, kan systemet eksempelvis afvise, forsinke eller kølægge yderligere anmodninger.

Hvorfor er begrebet vigtigt?

Rate limiting beskytter begrænset kapacitet og hjælper med at fordele den rimeligt mellem klienter. Det kan dæmpe utilsigtede trafikspidser, fejlbehæftede integrationer, automatiseret misbrug og omkostninger fra ressourcekrævende handlinger.

Effekten afhænger af designet. Teamet skal vælge, hvem eller hvad der tælles, hvilke operationer politikken omfatter, tidsvindue, burst-kapacitet og hvordan tællere deles mellem gatewayinstanser og regioner.

Typisk misforståelse

En rate limit er ikke automatisk en præcis, global maksimumgrænse. I distribuerede systemer kan tællere være lokale eller kun delvist synkroniserede, så en konfigureret grænse kan blive overskredet kortvarigt.

Rate limiting er heller ikke en fuld beskyttelse mod denial-of-service. Den erstatter ikke authentication, authorization, inputgrænser, timeouts, samtidighedsgrænser, Web Application Firewall (WAF), kapacitetsstyring eller beskyttelse længere ude i netværket.

Eksempel

En fiktiv ordre-API bruger en token bucket pr. tenant og operation. Politikken tillader en stabil hastighed på ti kald i sekundet og et kort burst på tyve kald. Det giver plads til normale spidsbelastninger uden at én tenant optager hele backendens kapacitet.

Når en bucket er tom, svarer gatewayen med 429 Too Many Requests og et Retry-After-felt. Klienten venter det angivne tidsrum og bruger derefter gradvist backoff med tilfældig variation, så mange klienter ikke prøver igen samtidigt. Teamet overvåger afvisninger og backendbelastning og justerer grænserne ud fra målinger.

Best practice

• Vælg en stabil nøgle, der afspejler den reelle forbruger; brug ikke IP-adressen alene, når mange klienter kan dele den.

• Definér både vedvarende hastighed, tilladte bursts og særskilte grænser for dyre eller følsomme operationer.

• Kombinér rate limits med kvoter, samtidighedsgrænser, payloadgrænser og omkostningskontroller.

• Håndhæv kontrollen før dyr behandling, og dokumentér hvordan tællere fungerer på tværs af instanser og regioner.

• Returnér tydelige fejl og relevante retry-oplysninger; klienter bør bruge backoff med tilfældig variation.

• Overvåg tilladte og afviste kald, latenstid og kapacitetsudnyttelse, og belastningstest politikken før produktion.