Hvad er rate limiting? En letforståelig guide for app-byggere
Rate limiting er en regel, der begrænser, hvor mange forespørgsler nogen kan sende til et system på et bestemt tidsrum — fx 5 loginforsøg i minuttet eller 100 API-kald i timen. Når grænsen er nået, afvises yderligere forespørgsler (typisk med fejlkoden 429 Too Many Requests), indtil tidsvinduet nulstilles. Det beskytter apps mod misbrug, forhindrer at én tung bruger gør det langsommere for alle, og stopper udgifter, der løber løbsk.
Du møder rate limiting fra to sider: tjenester, du kalder, begrænser dig, og din egen app bør begrænse sine brugere.
Hvorfor rate limiting betyder noget, når du bygger med AI
AI-byggede apps forbinder ofte til betalte tjenester — AI-modeller, e-mail, sms, kort — og hvert kald koster penge. Det gør rate limiting både til en sikkerhedsfunktion og en budgetfunktion.
- Omkostningskontrol. Hvis din app har en "spørg AI"-boks uden grænse, kan en bot sende den tusindvis af forespørgsler i løbet af natten. Du betaler for hver enkelt.
- Sikkerhed. Uden grænse på loginformularen kan en angriber prøve tusindvis af adgangskoder mod en konto. En grænse på nogle få forsøg i minuttet gør det upraktisk.
- At holde sig online. Ét fejlende script — nogle gange din egen kode, der sidder fast i en løkke — kan overbelaste din database og lægge appen ned.
- At respektere andre tjenesters grænser. Når din app kalder en ekstern API for ofte, er det dig, der får 429-fejlene, og funktioner går i stykker for dine brugere.
AI-builders bygger det, du beder om. Nævner du ikke grænser, udelades de ofte.
En hverdagsanalogi
Tænk på et kaffebars gratis-påfyldningspolitik: "Én gratis påfyldning pr. kunde pr. besøg."
- Den forhindrer ingen i at nyde kaffen.
- Den forhindrer én person i at stå ved disken hele dagen og fylde en termokande til hele kontoret.
- Når nogen beder om en fjerde påfyldning, siger baristaen høfligt "ikke lige nu" — det er
429.
En god rate limit er usynlig for almindelige kunder og bemærkes kun af nogen, der gør noget usædvanligt.
Sådan virker rate limiting
En rate limiter har brug for tre ting:
| Del | Spørgsmålet den besvarer | Eksempler |
|---|---|---|
| Hvem | Hvis forespørgsler tælles? | Pr. brugerkonto, pr. IP-adresse, pr. API-nøgle |
| Hvor mange | Hvad er grænsen? | 5, 60, 1.000 forespørgsler |
| Pr. hvilken tid | Over hvilket vindue? | Pr. sekund, minut, time, dag |
Når en forespørgsel kommer ind, tjekker appen tællingen for det "hvem". Under grænsen: forespørgslen går igennem, og tællingen stiger. Over grænsen: forespørgslen afvises.
Der er få almindelige måder at tælle på:
| Metode | Sådan virker den | Afvejning |
|---|---|---|
| Fast vindue | Tællingen nulstilles på uret — fx hvert minut på minuttet | Enkel, men tillader et udbrud ved kanten mellem to vinduer |
| Glidende vindue | Ser på de seneste 60 sekunder fra nu | Jævnere, lidt mere arbejde at beregne |
| Token bucket | Hver bruger har en spand, der fyldes med en jævn hastighed; hver forespørgsel bruger en token | Tillader korte udbrud, mens gennemsnittet holdes stabilt |
Tællingerne skal gemmes et hurtigt og delt sted. På en enkelt lille server fungerer hukommelsen. Når en app kører på flere maskiner, ligger tælleren typisk i et delt lager som Redis eller databasen, ellers tæller hver maskine for sig, og den reelle grænse bliver flere gange højere.
Hvordan et rate-limited svar ser ud
Når en forespørgsel er over grænsen, svarer en velopdragen API med:
- Statuskode
429 Too Many Requests. - Ofte en
Retry-After-header, der siger, hvor mange sekunder der skal ventes. - Nogle gange headers, der viser din grænse og hvor mange forespørgsler du har tilbage i dette vindue (navnene varierer mellem udbydere).
Din app bør reagere på et 429 ved at vente og forsøge igen senere — helst med exponential backoff, altså at vente lidt længere efter hvert mislykket forsøg (1 sekund, så 2, så 4) i stedet for at hamre løs på tjenesten.
Et eksempel: en AI-skriveassistent
Lad os sige, du har bygget en app, hvor brugere indsætter tekst og får en AI-omskrivning.
Uden grænser: nogen skriver et script, der sender 20.000 forespørgsler i løbet af natten. Din AI-udbyders regning stiger, og din konto rammer udbyderens egen rate limit, så rigtige brugere ser fejl hele formiddagen.
Med fornuftige grænser:
- Pr. indloggede bruger: 30 omskrivninger i timen på gratis-planen, 300 på betalte. Over grænsen ser brugeren: "Du har nået denne times grænse. Prøv igen om 12 minutter, eller opgrader."
- Pr. IP-adresse på tilmeldingsformularen: 5 tilmeldinger i timen, for at stoppe bots i at oprette tusindvis af gratis konti for at omgå grænsen pr. bruger.
- En forbrugsgrænse sat i din AI-udbyders dashboard som sidste forsvarslinje, hvis alt andet svigter.
- Håndtering af udbyderens grænser: hvis AI-udbyderen returnerer et 429, venter din server og forsøger en eller to gange mere, og viser derefter en venlig besked: "Travlt lige nu, prøv igen."
Grænserne kontrolleres på serveren. En grænse, der kun findes i browseren — fx at deaktivere knappen efter 30 klik — kan omgås af enhver, der kalder din API direkte.
Vigtige begreber
| Begreb | Betydning |
|---|---|
| Rate limit | Det maksimale antal forespørgsler, der er tilladt i et tidsvindue. |
| Kvote | En større tildeling, ofte pr. dag eller måned, nogle gange knyttet til en betalt plan. |
| 429 | HTTP-statuskoden for "for mange forespørgsler". |
| Retry-After | En svarheader, der siger, hvor længe der skal ventes, før der forsøges igen. |
| Throttling | At sætte forespørgsler langsommere ned eller afvise dem over en grænse. Bruges ofte som synonym. |
| Exponential backoff | At vente gradvist længere mellem forsøg. |
| Burst | Et kort udbrud af mange forespørgsler på én gang. |
| Brute-force-angreb | At prøve enorme mængder adgangskoder eller koder, indtil én virker. |
Almindelige misforståelser
- "Rate limiting er kun til store apps." Små apps er også mål, fordi bots scanner hele internettet for åbne formularer og AI-endpoints. Omkostningen ved misbrug afhænger ikke af din størrelse.
- "At skjule knappen er nok." Grænser i browseren er en høflighed, ikke beskyttelse. Rigtige grænser skal håndhæves på serveren.
- "Grænser pr. IP er altid fair." Mange mennesker kan dele én IP-adresse — et kontor, en skole, et mobilnet. Grænser pr. bruger er mere retfærdige, når folk er logget ind.
- "Et 429 betyder, at tjenesten er i stykker." Det betyder, at du kalder den for ofte. Tjek din kode for løkker, og cache resultater, der sjældent ændrer sig — se hvad caching er.
- "Rate limiting erstatter en forbrugsgrænse." Brug begge. Grænser i din app kan have fejl; udbyderens forbrugsgrænse er din sikkerhedsnet.
Hvad du beder din AI-builder om
- "Tilføj rate limiting på serveren til login, tilmelding, nulstilling af adgangskode og AI-endpointet. Foreslå fornuftige grænser."
- "Begræns hver indloggede bruger til [N] AI-forespørgsler i timen, og vis en tydelig besked med ventetiden, når de rammer grænsen."
- "Når en ekstern API returnerer 429, så forsøg igen med exponential backoff op til 3 gange, og vis derefter en venlig fejl."
- "Hvor gemmes tællerne for rate limits? Virker de stadig, hvis appen kører på mere end én maskine?"
- "Log hver gang en bruger eller IP rammer en grænse, så jeg kan opdage misbrug."
- "Hvilke eksterne tjenester kalder denne app, og hvad er deres rate limits?"
Rate limiting i Mythex
Mythex' dokumentation er tydelig om dette for AI-funktioner: rate limits, sikkerheds- og omkostningskontroller i apps, du bygger, er din opgave at designe — se Byg en AI-app. Bed agenten om at tilføje grænser i samme besked, hvor du beder om funktionen. På Pro kan en udgivet tjeneste køre på op til tre maskiner, når trafikken er høj (se Hosting-grænser), så bed om tællere, der ligger i databasen i stedet for i en enkelt servers hukommelse.
Relateret læsning: hvad er en API, sådan bruger du LLM-API'er og sikkerhedstjeklisten for AI-byggede apps.
Spørgsmål
Hvad er rate limiting med enkle ord?
Rate limiting er en regel, der begrænser, hvor mange forespørgsler en bruger, enhed eller app kan sende i en given periode — fx 5 loginforsøg i minuttet eller 100 API-kald i timen. Forespørgsler over grænsen afvises, indtil tidsvinduet nulstilles.
Hvad betyder fejlen 429 Too Many Requests?
HTTP-statuskode 429 betyder, at du har sendt for mange forespørgsler på for kort tid og har ramt en rate limit. Svaret indeholder ofte en Retry-After-header, der siger, hvor længe du skal vente. Løsningen er at sætte farten ned, forsøge igen efter en pause eller kalde tjenesten sjældnere.
Hvorfor har min AI-drevne app brug for rate limiting?
Hver AI-forespørgsel koster dig penge i tokens. Uden en grænse kan én bruger eller en bot sende tusindvis af forespørgsler og drive en stor regning op eller bruge din udbyderkvote op, så funktionen går ned for alle. Grænser pr. bruger holder omkostningerne forudsigelige.
Er rate limiting det samme som throttling?
De er tæt beslægtede og bruges ofte om hinanden. Rate limiting betyder typisk, at forespørgsler over en grænse afvises, mens throttling også kan betyde at sætte dem langsommere ned eller køe dem i stedet for at afvise dem direkte.
Stopper rate limiting DDoS-angreb?
Det hjælper mod små oversvømmelser og misbrug fra enkelte brugere eller IP-adresser, men et stort distribueret angreb kommer fra mange adresser på én gang. Beskyttelse mod dem sker typisk på netværks- eller CDN-niveau, før trafikken når din app.