Så skyddar du din AI-app mot överbelastning (för icke-kodare)

Konstruktivistisk modell i målat trä: ett svart torn, en tät rad smala stavar som en spärr och en mörk kula på en skena, genomskurna av en smal röd diagonal. En enda djup turkos detalj. — Ett oskyddat system försöker hantera allt samtidigt tills det kollapsar.

Varför kraschar appen?

När AI-verktyg som Cursor eller Claude bygger en app fokuserar de på att lösa huvuduppgiften (den "lyckliga vägen"). De skriver sällan kod som skyddar appen mot att överanvändas, om du inte uttryckligen ber om det.

Varje gång en användare klickar på "Skicka" i din app, belastar det systemets resurser — databasen, serverminnet eller din AI-leverantör (t.ex. OpenAI). Utan en spärr försöker din app hantera allt omedelbart. Till slut tar minnet slut, databasen låser sig eller API-leverantören blockerar dig för att du gör för många anrop för snabbt.

Lösningen: Rate Limiting

Rate limiting (hastighetsbegränsning) fungerar som en dörrvakt på en nattklubb. Den släpper in ett visst antal gäster per minut. Blir kön för lång får nästa person vänta utanför en liten stund, och i värsta fall (om det blir stormning) säger dörrvakten: "Tyvärr, försök igen om 10 minuter."

Genom att lägga till detta skydd säkerställer du att:

Din app aldrig försöker göra mer än den klarar av.
Illvilliga användare inte kan köra slut på din serverbudget (eller API-budget) genom att klicka 1000 gånger i sekunden.
Servern hinner andas och din databas hålls stabil.

Hur du ber AI:n fixa det

Som icke-kodare behöver du inte veta hur koden för rate limiting ser ut. Men du måste be AI:n bygga den. Klistra in följande prompt i ditt AI-verktyg när din app börjar fungera bra för en användare, men innan du släpper in fler:

Beställning: skydd mot överbelastning

Vi måste skydda appen mot överbelastning (rate limiting). Gör följande:

1. Lägg till en begränsning på våra API-anrop så att en enskild användare
   (per IP-adress eller per inloggad profil) max kan göra 10 förfrågningar
   per minut.
2. Om gränsen överskrids ska servern svara med "429 Too Many Requests" och
   gränssnittet visa: "Du arbetar lite för snabbt. Vänta en minut och
   försök igen."
3. Använd en standardlösning för det ramverk vi redan bygger i, till exempel
   en middleware. Hitta inte på en egen lösning.
4. Berätta för mig vilken gräns du satte och var i koden siffran står, så
   att jag kan ändra den själv senare.

Fjärde punkten är den som brukar glömmas. Om du inte vet var siffran står måste du be om hjälp varje gång den ska justeras, och den kommer att behöva justeras.

Vilken gräns ska du välja?

Tio per minut är en rimlig startpunkt för en app där en människa klickar sig fram. Men rätt siffra beror på vad ett anrop är i just din app, och det vet du bättre än någon mall. Räkna efter i stället för att gissa.

Använd appen som en vanlig användare i en minut. Räkna hur många gånger du skickar, sparar eller söker. Säg att det blir tre.

Multiplicera med tre eller fyra. Nio till tolv per minut blir då en gräns som en verklig användare aldrig märker av.

Kontrollera att du själv inte slår i den. Blir du spärrad under normal användning är gränsen för låg. Höj siffran — stäng inte av skyddet.

Sätt hellre gränsen för högt än för lågt i början. En för snäv spärr märks direkt av dina första riktiga användare och känns som att appen är trasig, medan en generös spärr fortfarande stoppar det den är till för: någon som gör tusen anrop i sekunden.

Två spärrar som lätt blandas ihop

Det finns två helt olika sätt att räkna, och AI-verktyg väljer ofta det enklare utan att fråga dig först.

Per användare. Var och en får sina tio per minut. Det är nästan alltid det du vill ha.
För hela appen. Alla användare delar på tio per minut tillsammans. Med fem samtidiga besökare spärrar appen ut sig själv.

Skillnaden syns inte förrän mer än en person använder appen samtidigt — alltså precis när det börjar spela roll. Det är därför det fjärde provet nedan finns: låt någon annan använda appen medan du själv är spärrad.

Spärra kostnaden, inte bara trafiken

Rate limiting skyddar din server. Den skyddar inte automatiskt din plånbok. Om appen skickar vidare varje förfrågan till en betald AI-tjänst kan tio anrop per minut per användare fortfarande bli en obehaglig faktura den dagen appen får uppmärksamhet. Leverantörerna har oftast ett eget utgiftstak som du sätter i deras kontrollpanel — det är en annan spärr än den i din kod, och du behöver båda.

Beställning: tak för kostnaden

Appen anropar en betald AI-tjänst och jag vill inte kunna bli
överraskad av en stor faktura. Gör två saker:

1. Lägg till ett tak i koden för hur många AI-anrop appen får göra
   per dygn totalt. När taket är nått ska appen visa ett vänligt
   meddelande i stället för att anropa tjänsten.
2. Tala om för mig var jag själv sätter ett utgiftstak hos
   leverantören, steg för steg, utan att förutsätta att jag kan koda.

Provet är detsamma som för spärren: sänk tillfälligt dygnstaket till ett par anrop, använd appen tills du slår i det, och kontrollera att du får meddelandet i stället för ett felmeddelande. Höj sedan tillbaka siffran.

Prova att skyddet faktiskt sitter

Att AI:n svarar "klart, jag har lagt till rate limiting" betyder inte att det fungerar. Du behöver inte läsa koden för att kontrollera det — du behöver bara använda appen lite för snabbt med flit. Gör det på din egen app, inte på någon annans.

Klicka femton gånger i rad. Skicka samma sak om och om igen, så fort du hinner. Räkna klicken.

Se efter var det tar stopp. Med gränsen tio per minut ska någonstans runt det elfte försöket ge det vänliga felmeddelandet i stället för ett vanligt svar.

Vänta en minut och prova en gång. Nu ska appen svara normalt igen. Gör den inte det är spärren för hård eller nollställs aldrig.

Be någon annan använda appen medan du är spärrad. Den personen ska kunna arbeta som vanligt. Blir även hen blockerad räknar spärren hela appen i klump i stället för per användare.

Blev det fel i något av de fyra proven är det inte ett misslyckande — det är precis den information AI:n behöver för att rätta. Beskriv vad du gjorde och vad som hände, i den ordningen; samma sätt att skriva som i en felrapport som går att använda.

Rate limiting skyddar mot för många anrop. Den gör inte appen snabbare. Om appen känns seg redan när du är ensam användare är orsaken en annan — börja då i stället med appen känns långsam.

Sammanfattning

AI bygger snabbt det som syns, men glömmer ofta det som skyddar. Rate limiting är den viktigaste "tråkiga" funktionen du måste lägga till innan du visar din app för världen. Tre saker gör jobbet: be om spärren med rätt termer, sätt en gräns du räknat fram i stället för gissat, och lägg ett eget tak på kostnaden. Gör sedan de fyra proven i förra avsnittet — det är skillnaden mellan att tro att skyddet finns och att veta det.