Vi satte rate limits på vores egne tjenester

Mythex' API tillader 300 forespørgsler i minuttet fra én netværksadresse. Grænsen findes for at beskytte os mod en enkelt person eller et script, der hamrer på API'et. I produktion begyndte den i stedet at afvise vores egne tjenester — den del af vores edge, der serverer publicerede apps, og tjenesten, der kører AI-agenten — fordi hver af dem kalder API'et fra kun en håndfuld adresser. Forespørgsler, der bærer vores interne credential, er nu undtaget, og alle andre begrænses præcis som før.

Symptomet

API'et begyndte at svare nogle af vores egne interne kald med 429 Too Many Requests. Tre slags kald blev ramt, og hver af dem betyder noget for nogen, der bruger Mythex:

• Opslag af hvilken app der bor på et custom domain. Når en besøgende åbner en publiceret app på sit eget domæne, spørger vores edge API'et, hvor siden ligger. Et 429 der betyder en besøgende, der ikke kan nå en side.
• Gemning af en kørende agentturn. Mens agenten arbejder, gemmes dens fremskridt løbende, så et svar overlever en opdatering eller en afbrudt forbindelse. Et 429 der betyder fremskridt, der ikke blev gemt.
• Tjek af adgang til et preview. Preview'et af en app, du bygger, er låst, og låsen spørger API'et. Et 429 der betyder et preview, der ikke åbner.

Ingen af disse var personer, der kaldte API'et. Alle var os.

Hvorfor det skete

En rate limit pr. adresse har én antagelse: én adresse er nogenlunde én bruger. For mennesker holder det nok. For vores egen infrastruktur er det alvorligt forkert.

• Edge-tjenesten, der serverer publicerede apps og previews, kalder API'et fra nogle få delte udgående adresser. Hver besøgende på hver publiceret app, og hvert preview-tjek, ankommer og ser ud til at komme fra en af de få.
• Orkestratoren — tjenesten, der kører agentturns — kalder API'et fra én container-adresse. Hver kørende tur, for hver bruger, deler den.

Så budgettet, der var beregnet til én person, blev delt op mellem al trafik fra en hel tjeneste. Tjenesterne brugte det op mellem sig, og grænsen gjorde det, den var sat op til: den afviste dem.

Rettelsen

Vores egne tjenester beviser allerede, hvem de er. Hvert internt kald bærer et internt token, og hver route under API'ets interne sektion tjekker det token, før den gør noget.

Rate limiteren bruger nu samme tjek. En forespørgsel, hvis token matcher det interne, står på en tilladelsesliste og tælles ikke med i budgettet pr. adresse. Alt andet tælles præcis som før: 300 forespørgsler i minuttet pr. adresse.

To detaljer forhindrede, at dette blev et hul:

1. Et forkert token får ingen adgang. Tilladelseslisten matcher kun det rigtige interne token. En forespørgsel med et opdigtet token tælles og begrænses som enhver anden, og de interne routes afviser den med 401 Unauthorized.
2. Grænsen selv blev ikke ændret. Vi hævede ikke tallet for at skabe plads. Det ville have skjult problemet, indtil trafikken voksede igen, og det ville have svækket beskyttelsen i det tilfælde, grænsen findes for.

Vi flyttede limiterens indstillinger ind i en lille funktion og skrev tests mod den. En sender 20 forespørgsler med det interne token til en limiter sat til at tillade 5, og forventer at alle 20 lykkes. En anden sender almindelige forespørgsler fra én adresse og forventer, at de første fem lykkes, og at dem efter afvises. En tredje sender forespørgsler med et forfalsket token og forventer, at de afvises på samme måde.

Det vi tog med

• Grænser bærer antagelser. "Én adresse, én kalder" er indbygget i en grænse pr. adresse. Den holder op med at være sand, så snart dine egne tjenester sidder bag delte adresser — og mange gør: load balancere, edge-netværk, containere, kontornetværk.
• Skil din egen trafik ad efter identitet, ikke adresse. Adresser er, hvordan trafik ankommer, ikke hvem der sendte den. Vi havde allerede en credential, der beviser, at et kald er vores; limiteren kiggede bare ikke på den.
• Ret det ikke ved at hæve tallet. En større grænse ville have fjernet 429'erne i et stykke tid, beskyttet mindre og fejlet igen senere.
• Kig på, hvem der bliver begrænset. Et 429, der rammer din egen tjeneste, er en fejlrapport om dine grænser, ikke et tegn på, at limiteren virker.

Hvad det betyder, hvis du bygger på Mythex

Ingen ændringer på din side. Publicerede apps på custom domains, agentturns og previews afhænger ikke længere af, hvor travlt resten af Mythex er. Din apps egen trafik er din apps sag: grænsen beskrevet her gælder vores API, ikke de apps, du publicerer.

Hvis du kører en egen backend, gælder den samme fælde for enhver rate limit, du tilføjer. Vores guider om hvad et API er og sikkerhedstjeklisten for AI-byggede apps er et godt sted at starte. Og for et andet tilfælde, hvor vores egen infrastruktur kom i vejen for sig selv, se hvordan vi fik udrulninger ned til nul 502-fejl.