Nilimitahan Namin ang Sarili Naming mga Serbisyo

Pinapayagan ng API ng Mythex ang 300 request kada minuto mula sa iisang network address. Umiiral ang limit na iyon para protektahan kami mula sa isang tao o script na pinapalo ang API. Sa production, nagsimula itong tanggihan ang sarili naming mga serbisyo, ang bahagi ng edge namin na nagse-serve ng mga na-publish na app at ang serbisyong nagpapatakbo ng AI agent, dahil bawat isa sa kanila ay umaabot sa API mula sa iilang address lang. Exempt na ngayon ang mga request na may dalang internal credential namin, at ang iba ay nililimitahan pa rin gaya ng dati.

Ang sintomas

Nagsimulang sagutin ng API ang ilan sa mga internal na tawag namin ng 429 Too Many Requests. Tatlong uri ng tawag ang tinamaan, at bawat isa ay mahalaga sa sinumang gumagamit ng Mythex:

Pagtingin kung aling app ang nasa custom domain. Kapag binubuksan ng bisita ang na-publish na app sa sarili nitong domain, tinatanong ng edge namin ang API kung nasaan ang site na iyon. Ang 429 doon ay bisitang hindi maabot ang site.
Pag-save ng tumatakbong agent turn. Habang gumagawa ang agent, sine-save ang progreso nito habang nagpapatuloy, para mabuhay ang sagot kahit mag-refresh o maputol ang koneksyon. Ang 429 doon ay progresong hindi na-save.
Pagsuri ng access sa preview. Protektado ang preview ng app na binubuo mo, at tinatanong ng gate na iyon ang API. Ang 429 doon ay preview na hindi mabuksan.

Wala sa mga ito ang taong tumatawag sa API. Lahat ng ito ay kami.

Bakit ito nangyari

May isang palagay ang per-address rate limit: ang isang address ay halos isang tumatawag. Para sa mga tao, sapat na malapit iyon. Para sa sarili naming imprastraktura, mali ito nang husto.

Ang edge service na nagse-serve ng mga na-publish na app at preview ay umaabot sa API mula sa iilang shared na outgoing address. Bawat bisita sa bawat na-publish na app, at bawat pagsuri ng preview, ay mukhang galing sa isa sa iilang iyon.
Ang orchestrator, ang serbisyong nagpapatakbo ng agent turns, ay umaabot sa API mula sa isang container address. Bawat tumatakbong turn, para sa bawat user, ay nagbabahagi nito.

Kaya ang budget na para sa isang tao lang ay hinahati sa lahat ng trapiko ng buong serbisyo. Naubos ito ng mga serbisyong iyon sa pagitan nila, at ginawa ng limiter ang inutos dito: tinanggihan sila.

Ang ayos

Ipinapatunay na ng aming mga serbisyo kung sino sila. Bawat internal na tawag ay may dalang internal token, at bawat route sa ilalim ng internal na seksyon ng API ay sinusuri ang token na iyon bago gawin ang anuman.

Gumagamit na ngayon ang rate limiter ng parehong pagsusuri. Ang request na may token na tugma sa internal ay nasa allow list at hindi binibilang laban sa per-address budget. Ang iba ay binibilang gaya ng dati: 300 request kada minuto bawat address.

Dalawang detalye ang pumigil na maging butas ito:

Walang pasaporte ang maling token. Ang allow list ay tumutugma lang sa totoong internal token. Ang request na may gawa-gawang token ay binibilang at nililimitahan gaya ng iba, at tinatanggihan pa rin ito ng internal routes ng 401 Unauthorized.
Hindi nagbago ang mismong limit. Hindi namin itinaas ang numero para magkaroon ng puwang. Ang pagtaas nito ay magtatago ng problema hanggang lumaki ulit ang trapiko, at magpapahina rin ito ng proteksyon para sa kasong pinaglalaanan ng limit.

Inilipat namin ang settings ng limiter sa isang maliit na function at sumulat ng mga test laban dito. Ang isa ay nagpapadala ng 20 request na may internal token sa limiter na ang pinapayagan ay 5, at inaasahang magtatagumpay ang lahat ng 20. Ang isa pa ay nagpapadala ng karaniwang request mula sa isang address, at inaasahang magtatagumpay ang unang lima at tatanggihan ang mga kasunod. Ang pangatlo ay nagpapadala ng request na may pekeng token, at inaasahang tatanggihan ito sa parehong paraan.

Ang natutunan namin

May dalang palagay ang mga limit. Nakabaon sa per-address limit ang "isang address, isang tumatawag". Hindi na ito totoo sa sandaling nasa likod ng shared na address ang sarili mong mga serbisyo, at marami sa kanila ang ganoon: load balancers, edge networks, containers, office networks.
Paghiwalayin ang sarili mong trapiko ayon sa pagkakakilanlan, hindi ayon sa address. Ang address ay paraan ng pagdating ng trapiko, hindi kung sino ang nagpadala nito. Mayroon na kaming credential na nagpapatunay na sa amin ang tawag; hindi lang ito tinitingnan ng limiter.
Huwag itong ayusin sa pagtaas ng numero. Mawawala sana ang mga 429 nang ilang panahon kung nagtaas ng limit, mas kaunti ang proteksyon, at babalik ang problema sa susunod.
Tingnan kung sino ang nililimitahan. Ang 429 na tumatama sa sarili mong serbisyo ay ulat ng bug tungkol sa iyong mga limit, hindi senyales na gumagana ang limiter.

Ano ang ibig sabihin nito kung nagbu-build ka sa Mythex

Wala kang kailangang baguhin sa panig mo. Ang mga na-publish na app sa custom domain, agent turns at preview ay hindi na nakadepende kung gaano ka-abala ang iba pang bahagi ng Mythex. Ang sariling trapiko ng app mo ay negosyo ng app mo: ang limit na inilarawan dito ay nasa API namin, hindi sa mga app na ina-publish mo.

Kung may sarili kang backend, pareho ang bitag para sa anumang rate limit na idaragdag mo. Magandang simulan sa aming mga gabay tungkol sa ano ang API at sa security checklist para sa AI-built apps. At para sa isa pang kaso ng sarili naming imprastraktura na humaharang sa sarili nito, tingnan ang paano namin nakuha ang deploys na zero 502 errors.