Vi begränsade våra egna tjänster

Mythex API tillåter 300 förfrågningar per minut från en nätverksadress. Gränsen finns för att skydda oss från att en enskild person eller ett skript bombarderar API:et. I produktion började den i stället neka våra egna tjänster, den del av vår edge som serverar publicerade appar och tjänsten som kör AI-agenten, eftersom var och en av dem når API:et från bara ett fåtal adresser. Förfrågningar som bär vår interna credential är nu undantagna, och alla andra begränsas precis som tidigare.

Symptomet

API:et började svara på några av våra egna interna anrop med 429 Too Many Requests. Tre typer av anrop drabbades, och vart och ett betyder något för någon som använder Mythex:

Att slå upp vilken app som finns på en egen domän. När en besökare öppnar en publicerad app på sin egen domän frågar vår edge API:et var sajten finns. Ett 429 där innebär en besökare som inte kan nå en sajt.
Att spara en pågående agentomgång. Medan agenten arbetar sparas dess framsteg allteftersom, så att ett svar överlever en uppdatering eller en bruten anslutning. Ett 429 där innebär framsteg som inte sparades.
Att kontrollera åtkomst till en förhandsvisning. Förhandsvisningen av en app du bygger är spärrad, och spärren frågar API:et. Ett 429 där innebär en förhandsvisning som inte öppnas.

Ingen av dessa var personer som anropade API:et. Alla var vi.

Varför det hände

En gräns per adress gör ett antagande: en adress är ungefär en anropare. För människor stämmer det tillräckligt bra. För vår egen infrastruktur är det helt fel.

Edge-tjänsten som serverar publicerade appar och förhandsvisningar når API:et från några få delade utgående adresser. Varje besökare på varje publicerad app, och varje kontroll av förhandsvisning, kommer in och ser ut att komma från någon av dessa få.
Orkestratorn, tjänsten som kör agentomgångar, når API:et från en enda containeradress. Varje pågående omgång, för varje användare, delar den.

Budgeten som var till för en person delades alltså av all trafik från en hel tjänst. Tjänsterna förbrukade den tillsammans, och begränsaren gjorde det den var satt att göra: den nekade dem.

Lösningen

Våra egna tjänster bevisar redan vilka de är. Varje internt anrop bär en intern token, och varje route under API:ets interna sektion kontrollerar den tokenen innan den gör något.

Begränsaren använder nu samma kontroll. En förfrågan vars token matchar den interna tokenen står på en tillåtelselista och räknas inte mot budgeten per adress. Allt annat räknas precis som förut: 300 förfrågningar per minut per adress.

Två detaljer gjorde att detta inte blev ett hål:

En fel token får ingen passage. Tillåtelselistan matchar bara den riktiga interna tokenen. En förfrågan med en påhittad token räknas och stryps som alla andra, och de interna routerna avvisar den ändå med 401 Unauthorized.
Gränsen i sig ändrades inte. Vi höjde inte talet för att skapa utrymme. Att höja det hade dolt problemet tills trafiken växte igen, och försvagat skyddet för det fall som gränsen finns för.

Vi flyttade begränsarens inställningar till en liten funktion och skrev tester mot den. Ett skickar 20 förfrågningar med den interna tokenen till en begränsare satt att tillåta 5, och förväntar sig att alla 20 lyckas. Ett annat skickar vanliga förfrågningar från en adress och förväntar sig att de första fem lyckas och de efterföljande nekas. Ett tredje skickar förfalskade tokens och förväntar sig att de nekas på samma sätt.

Det vi tog med oss

Gränser bär på antaganden. “En adress, en anropare” är inbyggt i en gräns per adress. Det slutar gälla i samma ögonblick som dina egna tjänster sitter bakom delade adresser, och många gör det: load balancers, edge-nätverk, containrar, kontorsnät.
Skilj din egen trafik åt med identitet, inte med adress. Adresser är hur trafiken kommer fram, inte vem som skickade den. Vi hade redan en credential som bevisar att ett anrop är vårt; begränsaren tittade bara inte på den.
Lös det inte genom att höja talet. En större gräns hade fått 429:orna att försvinna en stund, skyddat mindre, och misslyckats igen senare.
Titta på vem som stryps. Ett 429 som landar på din egen tjänst är en buggrapport om dina gränser, inte ett tecken på att begränsaren fungerar.

Vad det betyder om du bygger på Mythex

Du behöver inte ändra något. Publicerade appar på egna domäner, agentomgångar och förhandsvisningar är inte längre beroende av hur upptaget resten av Mythex är. Din apps egen trafik är din apps sak: gränsen som beskrivs här gäller vårt API, inte apparna du publicerar.

Om du kör en egen backend gäller samma fälla för alla rate limits du lägger till. Våra guider om vad ett API är och säkerhetschecklistan för AI-byggda appar är ett bra ställe att börja. Och för ett annat fall där vår egen infrastruktur kom i vägen för sig själv, se hur vi fick deploys ner till noll 502-fel.