We beperkten onze eigen services met rate limits

De API van Mythex staat 300 verzoeken per minuut per netwerkadres toe. Die limiet bestaat om ons te beschermen tegen één persoon of script dat de API bestookt. In productie begon hij onze eigen services te weigeren: het deel van onze edge dat gepubliceerde apps serveert, en de service die de AI-agent draait, omdat elk van die twee de API vanaf een handvol adressen benadert. Verzoeken met onze interne credential zijn nu vrijgesteld, en iedereen anders wordt beperkt precies zoals voorheen.

Het symptoom

De API begon sommige van onze eigen interne aanroepen te beantwoorden met 429 Too Many Requests. Drie soorten aanroepen werden geraakt, en elk daarvan is belangrijk voor iemand die Mythex gebruikt:

Opzoeken welke app op een eigen domein staat. Wanneer een bezoeker een gepubliceerde app op zijn eigen domein opent, vraagt onze edge de API waar die site staat. Een 429 daar betekent een bezoeker die een site niet kan bereiken.
Een lopende agentbeurt opslaan. Terwijl de agent werkt, wordt de voortgang onderweg opgeslagen, zodat een antwoord een refresh of een verbroken verbinding overleeft. Een 429 daar betekent voortgang die niet is opgeslagen.
Toegang tot een preview controleren. De preview van een app die je bouwt, is afgeschermd, en de poort vraagt de API. Een 429 daar betekent een preview die niet opent.

Geen van deze kwam van mensen die de API aanriepen. Ze kwamen allemaal van ons.

Waarom het gebeurde

Een rate limit per adres gaat uit van één aanname: één adres is ongeveer één aanroeper. Voor mensen klopt dat redelijk. Voor onze eigen infrastructuur klopt het slecht.

De edgedienst die gepubliceerde apps en previews serveert, benadert de API vanaf een paar gedeelde uitgaande adressen. Elke bezoeker van elke gepubliceerde app, en elke previewcontrole, komt over als afkomstig van een van die weinige.
De orchestrator, de dienst die agentbeurten draait, benadert de API vanaf één containeradres. Elke lopende beurt, voor elke gebruiker, deelt dat.

Dus werd het budget bedoeld voor één persoon verdeeld over al het verkeer van een hele dienst. Die diensten gebruikten het samen op, en de limiter deed wat hij moest doen: hij weigerde ze.

De oplossing

Onze eigen diensten bewijzen al wie ze zijn. Elke interne aanroep draagt een intern token, en elke route onder het interne gedeelte van de API controleert dat token voordat hij iets doet.

De rate limiter gebruikt nu dezelfde controle. Een verzoek waarvan het token overeenkomt met het interne token staat op een allowlist en telt niet mee in het budget per adres. Al het andere telt precies zoals voorheen: 300 verzoeken per minuut per adres.

Twee details voorkwamen dat dit een gat werd:

Een verkeerd token krijgt geen vrijstelling. De allowlist past alleen het echte interne token. Een verzoek met een verzonnen token wordt geteld en beperkt zoals elk ander, en de interne routes weigeren het met 401 Unauthorized.
De limiet zelf is niet veranderd. We hebben het getal niet verhoogd om ruimte te maken. Dat had het probleem verborgen tot het verkeer weer groeide, en de bescherming verzwakt voor het geval waarvoor de limiet bestaat.

We hebben de instellingen van de limiter in één kleine functie gezet en tests ertegen geschreven. Eén stuurt 20 verzoeken met het interne token naar een limiter die er 5 toestaat, en verwacht dat alle 20 slagen. Een ander stuurt gewone verzoeken vanaf één adres en verwacht dat de eerste vijf slagen en de rest wordt geweigerd. Een derde stuurt verzoeken met een vervalst token en verwacht dat ze op dezelfde manier worden geweigerd.

Wat we eruit haalden

Limieten dragen aannames. „Één adres, één aanroeper” zit ingebakken in een limiet per adres. Het klopt niet meer zodra je eigen diensten achter gedeelde adressen zitten, en dat doen veel diensten: load balancers, edge-netwerken, containers, kantoornetwerken.
Onderscheid je eigen verkeer op identiteit, niet op adres. Adressen zijn hoe verkeer aankomt, niet wie het stuurde. We hadden al een credential dat bewijst dat een aanroep van ons is; de limiter keek er alleen niet naar.
Los het niet op door het getal te verhogen. Een grotere limiet had de 429's even laten verdwijnen, minder beschermd en later opnieuw gefaald.
Kijk naar wie wordt beperkt. Een 429 die op je eigen dienst terechtkomt, is een bugmelding over je limieten, geen teken dat de limiter werkt.

Wat het betekent als je op Mythex bouwt

Je hoeft niets aan te passen. Gepubliceerde apps op eigen domeinen, agentbeurten en previews zijn niet langer afhankelijk van hoe druk de rest van Mythex is. Het verkeer van je eigen app is de zaak van je app: de limiet hier beschreven geldt voor onze API, niet voor de apps die jij publiceert.

Als je zelf een backend draait, geldt dezelfde valkuil voor elke rate limit die je toevoegt. Onze gidsen over wat een API is en de beveiligingschecklist voor met AI gebouwde apps zijn een goed startpunt. En voor een ander geval waarin onze eigen infrastructuur zichzelf in de weg zat, zie hoe we deploys tot nul 502-fouten terugbrachten.