Hva er rate limiting? En forklaring på vanlig språk for app-byggere

Rate limiting er en regel som begrenser hvor mange forespørsler noen kan sende til et system i et bestemt tidsrom – for eksempel 5 innloggingsforsøk per minutt, eller 100 API-kall per time. Når grensen er nådd, avvises videre forespørsler (vanligvis med feilkoden 429 Too Many Requests) til tidsvinduet nullstilles. Det beskytter apper mot misbruk, forhindrer at én tung bruker gjør det tregere for alle, og stopper ukontrollerte kostnader.

Du møter rate limiting fra to sider: tjenester du kaller begrenser deg, og din egen app bør begrense brukerne sine.

Hvorfor rate limiting betyr noe når du bygger med AI

AI-bygde apper kobler seg ofte til betalte tjenester – AI-modeller, e-post, SMS, kart – og hvert kall koster penger. Det gjør rate limiting til både en sikkerhetsfunksjon og en budsjettfunksjon.

• Kostnadskontroll. Hvis appen din har en «spør AI»-boks uten grense, kan en bot sende den tusenvis av forespørsler over natten. Du betaler for hver eneste en.
• Sikkerhet. Uten grense på innloggingsskjemaet kan en angriper prøve tusenvis av passord mot én konto. En grense på noen få forsøk per minutt gjør det upraktisk.
• Holde seg oppe. Ett skript som oppfører seg feil – noen ganger koden din selv, fast i en løkke – kan overbelaste databasen og slå ned appen.
• Respektere andre tjenesters grenser. Når appen din kaller et eksternt API for ofte, er det du som får 429-feilene, og funksjoner brytes for brukerne dine.

AI-verktøy bygger det du ber om. Hvis du ikke nevner grenser, blir de ofte utelatt.

En hverdagslig analogi

Tenk på et kafés regler for gratis påfyll: «Ett gratis påfyll per kunde per besøk.»

• Det hindrer ikke noen i å nyte kaffen sin.
• Det hindrer én person i å stå ved disken hele dagen og fylle på en termos til hele kontoret.
• Når noen ber om et fjerde påfyll, sier baristaen høflig «ikke nå» – det er 429-en.

En god grense er usynlig for vanlige kunder og merkes bare av noen som gjør noe uvanlig.

Hvordan rate limiting fungerer

En rate limiter trenger tre ting:

Når en forespørsel kommer inn, sjekker appen telleren for den «hvem». Under grensen: forespørselen går gjennom og telleren går opp. Over grensen: forespørselen avvises.

Det finnes noen vanlige måter å telle på:

Tellerne må lagres et sted som er raskt og delt. På én liten server fungerer minnet. Når appen kjører på flere maskiner, ligger telleren vanligvis i en delt lagring som Redis eller databasen, ellers teller hver maskin for seg, og den reelle grensen blir flere ganger høyere.

Hvordan en avvist forespørsel ser ut

Når en forespørsel er over grensen, svarer et ordentlig API med:

• Statuskode 429 Too Many Requests.
• Ofte en Retry-After-header, som sier hvor mange sekunder du skal vente.
• Noen ganger headere som viser grensen din og hvor mange forespørsler du har igjen i dette vinduet (navnene varierer mellom leverandører).

Appen din bør svare på en 429 ved å vente og prøve igjen senere – helst med eksponentiell backoff, som betyr å vente litt lenger etter hvert mislykket forsøk (1 sekund, så 2, så 4) i stedet for å hamre på tjenesten.

Et arbeidseksempel: en AI-skrivehjelper

Si at du har bygget en app der brukere limer inn tekst og får en AI-omskrivning.

Uten grenser: noen skriver et skript som sender 20 000 forespørsler over natten. Regningen hos AI-leverandøren din stiger, og kontoen din treffer leverandørens egen grense, så ekte brukere ser feil hele morgenen.

Med fornuftige grenser:

1. Per innlogget bruker: 30 omskrivinger per time på gratisplanen, 300 på betalt. Over grensen ser brukeren: «Du har nådd grensen for denne timen. Prøv igjen om 12 minutter, eller oppgrader.»
2. Per IP-adresse på registreringsskjemaet: 5 registreringer per time, for å stoppe boter som oppretter tusenvis av gratiskontoer for å omgå grensen per bruker.
3. En utgiftsgrense satt i AI-leverandørens dashbord, som et siste sikkerhetsnett hvis alt annet svikter.
4. Håndtere leverandørens grenser: hvis AI-leverandøren returnerer en 429, venter serveren din og prøver en eller to ganger til, og viser så en vennlig «opptatt, prøv igjen»-melding.

Grensene sjekkes på serveren. En grense som bare finnes i nettleseren – for eksempel å deaktivere knappen etter 30 klikk – kan omgås av alle som kaller API-et ditt direkte.

Viktige begreper

Vanlige misforståelser

• «Rate limiting er bare for store apper.» Små apper er også mål, fordi boter skanner hele internett etter åpne skjemaer og AI-endepunkter. Kostnaden ved misbruk avhenger ikke av størrelsen din.
• «Det er nok å skjule knappen.» Grenser i nettleseren er en høflighet, ikke beskyttelse. Ekte grenser må håndheves på serveren.
• «Grenser per IP-adresse er alltid rettferdige.» Mange mennesker kan dele én IP-adresse – et kontor, en skole, et mobilnett. Grenser per bruker er rettferdigere når folk er innlogget.
• «En 429 betyr at tjenesten er ødelagt.» Den betyr at du kaller den for ofte. Sjekk koden din for løkker, og cache resultater som ikke endrer seg ofte – se hva caching er.
• «Rate limiting erstatter en utgiftsgrense.» Bruk begge. Grenser i appen kan ha feil; leverandørens utgiftsgrense er sikkerhetsnettet ditt.

Hva du bør be AI-byggeren din om

• «Legg til rate limiting på serversiden for innlogging, registrering, tilbakestilling av passord og AI-endepunktet. Foreslå fornuftige grenser.»
• «Begrens hver innlogget bruker til [N] AI-forespørsler per time, og vis en tydelig melding med ventetiden når grensen er nådd.»
• «Når et eksternt API returnerer 429, prøv igjen med eksponentiell backoff opptil 3 ganger, og vis deretter en vennlig feilmelding.»
• «Hvor lagres tellerne for rate limiting? Vil de fungere hvis appen kjører på mer enn én maskin?»
• «Logg hver gang en bruker eller IP-adresse treffer en grense, så jeg kan oppdage misbruk.»
• «Hvilke eksterne tjenester kaller denne appen, og hva er grensene deres?»

Rate limiting i Mythex

Mythex-dokumentasjonen er tydelig på dette for AI-funksjoner: rate limits, sikkerhet og kostnadskontroller i apper du bygger, er dine å designe – se Bygg en AI-app. Be agenten om å legge til grenser i samme melding som du ber om funksjonen. På Pro kan en publisert tjeneste kjøre på opptil tre maskiner når trafikken er stor (se Hosting-grenser), så be om tellere som ligger i databasen i stedet for i minnet til én server.

Relatert lesestoff: hva et API er, hvordan bruke LLM-API-er og sikkerhetssjekklisten for AI-bygde apper.

Spørsmål