Vad är rate limiting? En lättförståelig guide för appbyggare
Rate limiting är en regel som begränsar hur många förfrågningar någon kan göra till ett system under en viss tid – till exempel 5 inloggningsförsök per minut, eller 100 API-anrop per timme. När gränsen är nådd nekas ytterligare förfrågningar (vanligtvis med felkoden 429 Too Many Requests) tills tidsfönstret återställs. Det skyddar appar mot missbruk, hindrar en enskild tung användare från att göra allt långsammare för alla andra och stoppar kostnader som löper iväg.
Du möter rate limiting från två håll: tjänster du anropar begränsar dig, och din egen app bör begränsa sina användare.
Varför rate limiting spelar roll när du bygger med AI
AI-byggda appar kopplar ofta upp sig mot betaltjänster – AI-modeller, e-post, SMS, kartor – och varje anrop kostar pengar. Det gör rate limiting både till en säkerhetsfunktion och en budgetfunktion.
- Kostnadskontroll. Om din app har en ”fråga AI”-ruta utan gräns kan en bot skicka tusentals förfrågningar över natten. Du betalar för varje en.
- Säkerhet. Utan gräns på inloggningsformuläret kan en angripare prova tusentals lösenord mot ett konto. En gräns på några försök per minut gör det opraktiskt.
- Att hålla sig igång. Ett enda felaktigt skript – ibland din egen kod som fastnat i en loop – kan överbelasta din databas och slå ut appen.
- Att respektera andra tjänsters gränser. När din app anropar ett externt API för ofta är det du som får 429-felen, och funktioner slutar fungera för dina användare.
AI-byggare bygger det du ber om. Om du inte nämner gränser utelämnas de ofta.
En vardaglig jämförelse
Tänk på ett kafé med regeln ”En gratis påfyllning per kund och besök”.
- Det hindrar ingen från att njuta av sitt kaffe.
- Det hindrar en person från att stå vid disken hela dagen och fylla på en termos till hela kontoret.
- När någon ber om en fjärde påfyllning säger personalen vänligt ”inte just nu” – det är
429.
En bra gräns är osynlig för vanliga kunder och märks bara av någon som gör något ovanligt.
Så fungerar rate limiting
En rate limiter behöver tre saker:
| Del | Frågan den besvarar | Exempel |
|---|---|---|
| Vem | Vars förfrågningar räknas? | Per användarkonto, per IP-adress, per API-nyckel |
| Hur många | Vad är gränsen? | 5, 60, 1 000 förfrågningar |
| Per vilken tid | Över vilket fönster? | Per sekund, minut, timme, dygn |
När en förfrågan kommer in kontrollerar appen räknarvärdet för det ”vem”. Under gränsen: förfrågan går igenom och räknaren ökar. Över gränsen: förfrågan nekas.
Det finns några vanliga sätt att räkna:
| Metod | Hur den fungerar | Avvägning |
|---|---|---|
| Fast fönster | Räknaren nollställs på klockan – t.ex. varje minut på minuten | Enkel, men tillåter en skur vid gränsen mellan två fönster |
| Glidande fönster | Tittar på de senaste 60 sekunderna från nu | Jämnare, något mer beräkning |
| Token-bucket | Varje användare har en hink som fylls på i jämn takt; varje förfrågan tar en token | Tillåter korta skurar medan medelvärdet hålls stabilt |
Räknarna måste lagras någonstans snabbt och delat. På en liten enskild server räcker minnet. När en app kör på flera maskiner ligger räknaren oftast i en delad lagring som Redis eller databasen; annars räknar varje maskin för sig och den verkliga gränsen blir flera gånger högre.
Hur ett svar med rate limit ser ut
När en förfrågan är över gränsen svarar ett välskrivet API med:
- Statuskod
429 Too Many Requests. - Ofta en
Retry-After-header, som anger hur många sekunder du ska vänta. - Ibland headers som visar din gräns och hur många förfrågningar du har kvar i det här fönstret (namnen varierar mellan leverantörer).
Din app bör svara på en 429 genom att vänta och försöka igen senare – helst med exponentiell backoff, vilket betyder att man väntar lite längre efter varje misslyckat försök (1 sekund, sedan 2, sedan 4) i stället för att bombardera tjänsten.
Ett genomgånget exempel: en AI-skrivassistent
Säg att du byggt en app där användare klistrar in text och får en AI-omskrivning.
Utan gränser: någon skriver ett skript som skickar 20 000 förfrågningar över natten. Din AI-leverantörs räkning rusar i höjden, och ditt konto når leverantörens egen rate limit, så riktiga användare ser fel hela förmiddagen.
Med rimliga gränser:
- Per inloggad användare: 30 omskrivningar per timme i gratisplanen, 300 på betalda planer. Över gränsen ser användaren: ”Du har nått den här timmens gräns. Försök igen om 12 minuter, eller uppgradera.”
- Per IP-adress på registreringsformuläret: 5 registreringar per timme, för att stoppa botar från att skapa tusentals gratiskonton för att kringgå gränsen per användare.
- En utgiftsgräns satt i din AI-leverantörs instrumentpanel, som en sista försvarslinje om allt annat faller.
- Hantera leverantörens gränser: om AI-leverantören returnerar en 429 väntar din server och försöker en eller två gånger till, och visar sedan ett vänligt meddelande om ”upptaget, försök igen”.
Gränserna kontrolleras på servern. En gräns som bara finns i webbläsaren – till exempel att inaktivera knappen efter 30 klick – kan kringgås av vem som helst som anropar ditt API direkt.
Viktiga begrepp
| Begrepp | Betydelse |
|---|---|
| Rate limit | Det högsta antal förfrågningar som tillåts inom ett tidsfönster. |
| Kvot | En större tilldelning, ofta per dygn eller månad, ibland kopplad till en betald plan. |
| 429 | HTTP-statuskoden för ”för många förfrågningar”. |
| Retry-After | En svarsheader som anger hur länge du ska vänta innan du försöker igen. |
| Throttling | Att sakta ner eller neka förfrågningar över en gräns. Används ofta som synonym. |
| Exponentiell backoff | Att vänta allt längre mellan försöken. |
| Skur (burst) | Ett kort utbrott av många förfrågningar samtidigt. |
| Brute-force-attack | Att prova enorma mängder lösenord eller koder tills en fungerar. |
Vanliga missuppfattningar
- ”Rate limiting är bara för stora appar.” Små appar är också mål, eftersom botar söker igenom hela internet efter öppna formulär och AI-endpoints. Kostnaden för missbruk beror inte på din storlek.
- ”Att dölja knappen räcker.” Gränser i webbläsaren är artighet, inte skydd. Riktiga gränser måste tillämpas på servern.
- ”Gränser per IP är alltid rättvisa.” Många personer kan dela en IP-adress – ett kontor, en skola, ett mobilnät. Gränser per användare är rättvisare när folk är inloggade.
- ”En 429 betyder att tjänsten är trasig.” Det betyder att du anropar den för ofta. Leta efter loopar i din kod, och cacha resultat som inte ändras ofta – se vad caching är.
- ”Rate limiting ersätter en utgiftsgräns.” Använd båda. Gränser i din app kan ha buggar; leverantörens utgiftsgräns är ditt sista skydd.
Vad du kan be din AI-byggare om
- ”Lägg till rate limiting på serversidan för inloggning, registrering, lösenordsåterställning och AI-endpointen. Föreslå rimliga gränser.”
- ”Begränsa varje inloggad användare till [N] AI-förfrågningar per timme, och visa ett tydligt meddelande med väntetiden när gränsen nås.”
- ”När ett externt API returnerar 429, försök igen med exponentiell backoff upp till 3 gånger, och visa sedan ett vänligt felmeddelande.”
- ”Var lagras räknarna för rate limit? Fungerar de fortfarande om appen körs på fler än en maskin?”
- ”Logga varje gång en användare eller IP-adress når en gräns, så att jag kan upptäcka missbruk.”
- ”Vilka externa tjänster anropar den här appen, och vilka rate limits har de?”
Rate limiting i Mythex
Mythex dokumentation är tydlig om detta för AI-funktioner: rate limits, säkerhet och kostnadskontroller i appar du bygger är din uppgift att utforma – se Bygg en AI-app. Be agenten lägga till gränser i samma meddelande där du ber om funktionen. På Pro kan en publicerad tjänst köras på upp till tre maskiner när trafiken är hög (se Hosting-gränser), så be om räknare som lever i databasen i stället för i en enskild servers minne.
Relaterad läsning: vad ett API är, hur du använder LLM-API:er och säkerhetschecklistan för AI-byggda appar.
Frågor
Vad är rate limiting med enkla ord?
Rate limiting är en regel som begränsar hur många anrop en användare, enhet eller app kan göra under en given period – till exempel 5 inloggningsförsök per minut eller 100 API-anrop per timme. Anrop över gränsen nekas tills tidsfönstret återställs.
Vad betyder felet 429 Too Many Requests?
HTTP-status 429 betyder att du skickat för många förfrågningar på för kort tid och nått en gräns. Svaret innehåller ofta en Retry-After-header som anger hur länge du ska vänta. Lösningen är att sakta ner, försöka igen efter en paus eller minska hur ofta din app anropar tjänsten.
Varför behöver min AI-drivna app rate limiting?
Varje AI-förfrågan kostar pengar i tokens. Utan en gräns kan en användare eller en bot skicka tusentals förfrågningar och driva upp en stor räkning eller använda upp din leverantörskvot, vilket slår ut funktionen för alla. Gränser per användare gör kostnaderna förutsägbara.
Är rate limiting samma sak som throttling?
De är nära besläktade och används ofta om varandra. Rate limiting innebär vanligtvis att förfrågningar över en gräns avvisas, medan throttling också kan betyda att de bromsas upp eller köas i stället för att direkt nekas.
Stoppar rate limiting DDoS-attacker?
Det hjälper mot små översvämningar och missbruk från enskilda användare eller IP-adresser, men en stor distribuerad attack kommer från många adresser samtidigt. Skydd mot sådant sker vanligtvis på nätverks- eller CDN-nivå, innan trafiken når din app.