Ano ang Rate Limiting? Gabay sa Simpleng Wika para sa App Builder

Ang rate limiting ay patakarang naglilimita kung ilang request ang maaaring gawin ng isang tao sa isang sistema sa itinakdang oras — halimbawa, 5 login attempt bawat minuto, o 100 API call bawat oras. Kapag naabot na ang limitasyon, tinatanggihan ang mga susunod na request (kadalasan may error code na 429 Too Many Requests) hanggang sa mag-reset ang time window. Pinoprotektahan nito ang app laban sa pang-aabuso, pinipigilan ang isang mabigat na user na magpabagal sa lahat, at pinipigilan ang lumalaking gastos.

Nakikita mo ang rate limiting mula sa dalawang panig: ang mga serbisyong tinatawag mo ay naglilimita sa iyo, at ang sarili mong app ay dapat maglimita sa mga user nito.

Bakit mahalaga ang rate limiting kapag gumagawa ka gamit ang AI

Madalas kumonekta ang mga app na gawa ng AI sa mga bayad na serbisyo — AI model, email, SMS, mapa — at may gastos ang bawat tawag. Kaya ang rate limiting ay parehong feature sa seguridad at feature sa badyet.

• Kontrol sa gastos. Kung may "ask AI" box ang app mo at walang limitasyon, maaaring magpadala ang bot ng libu-libong request magdamag. Binabayaran mo ang bawat isa.
• Seguridad. Kung walang limitasyon sa login form, maaaring subukan ng attacker ang libu-libong password sa isang account. Ang limit na ilang attempt bawat minuto ay nagpapahirap sa ganitong atake.
• Manatiling online. Ang isang script na nagkakamali — minsan ang sarili mong code na naka-loop — ay maaaring mag-overload sa database mo at magpabagsak sa app.
• Paggalang sa limitasyon ng ibang serbisyo. Kapag masyadong madalas tumawag ang app mo sa isang outside API, ikaw ang nakakatanggap ng mga 429 error, at nasisira ang mga feature para sa mga user mo.

Gagawin ng AI builder ang hinihingi mo. Kapag hindi mo binanggit ang limitasyon, kadalasan ay nawawala ang mga ito.

Pang-araw-araw na paghahalintulad

Isipin ang patakaran ng coffee shop sa libreng refill: "Isang libreng refill bawat customer kada bisita."

• Hindi nito pinipigilan ang sinuman na mag-enjoy ng kape.
• Pinipigilan nito ang isang tao na tumayo sa counter buong araw para magrefill ng flask para sa buong opisina.
• Kapag humingi ang isang tao ng ikaapat na refill, magalang na sasabihin ng barista na "hindi muna ngayon" — iyon ang 429.

Ang mabuting rate limit ay hindi napapansin ng karaniwang customer at napapansin lamang ng taong gumagawa ng kakaiba.

Paano gumagana ang rate limiting

Kailangan ng rate limiter ng tatlong bagay:

Kapag may dumating na request, tinitingnan ng app ang bilang para sa "sino" na iyon. Nasa ilalim ng limitasyon: dumadaan ang request at tumataas ang bilang. Lumampas sa limitasyon: tinatanggihan ang request.

May ilang karaniwang paraan ng pagbibilang:

Kailangang naka-store ang mga bilang sa lugar na mabilis at shared. Sa iisang maliit na server, sapat na ang memory. Kapag tumakbo na ang app sa maraming makina, kadalasang nasa shared store tulad ng Redis o database ang counter, kung hindi ay bibilangin ng bawat makina nang hiwalay at ang totoong limitasyon ay magiging ilang beses na mas mataas.

Ano ang itsura ng sagot kapag na-rate-limit

Kapag lumampas sa limitasyon ang request, ang maayos na API ay sumasagot ng:

• Status code na 429 Too Many Requests.
• Kadalasan ay Retry-After header, na nagsasabi kung ilang segundo ang hihintayin.
• Minsan ay mga header na nagpapakita ng limitasyon mo at kung ilang request pa ang natitira sa window na ito (nag-iiba ang pangalan ayon sa provider).

Dapat tumugon ang app mo sa 429 sa pamamagitan ng paghihintay at pag-retry pagkatapos — mainam gamit ang exponential backoff, na nangangahulugang mas matagal na paghihintay pagkatapos ng bawat nabigong subok (1 segundo, saka 2, saka 4) sa halip na paulit-ulit na kumatok sa serbisyo.

Halimbawang gawa: isang AI writing assistant

Ipagpalagay na gumawa ka ng app kung saan nagpa-paste ng teksto ang mga user at nakakakuha ng AI rewrite.

Kapag walang limitasyon: may sumulat ng script na nagpapadala ng 20,000 request magdamag. Tumataas ang bill ng AI provider mo, at naaabot ng account mo ang sariling rate limit ng provider, kaya nakakakita ng error ang mga totoong user buong umaga.

Kapag may makatwirang limitasyon:

1. Bawat naka-sign in na user: 30 rewrite bawat oras sa libreng plano, 300 sa bayad. Kapag lumampas, makikita ng user: "Naabot mo na ang limitasyon ng oras na ito. Subukan muli sa loob ng 12 minuto, o mag-upgrade."
2. Bawat IP address sa sign-up form: 5 sign-up bawat oras, para pigilan ang mga bot na gumawa ng libu-libong libreng account para lampasan ang per-user na limitasyon.
3. Spending cap na itinakda sa dashboard ng AI provider, bilang huling depensa kung pumalpak ang lahat ng iba.
4. Paghawak sa limitasyon ng provider: kapag nagbalik ng 429 ang AI provider, maghihintay at mag-retry ang server nang isa o dalawang beses, saka magpapakita ng magiliw na mensaheng "abala, subukan muli".

Sa server chine-check ang mga limitasyon. Ang limitasyong nasa browser lamang — halimbawa, pag-disable ng button pagkatapos ng 30 click — ay malalampasan ng sinumang direktang tatawag sa API mo.

Mga pangunahing termino

Mga karaniwang maling akala

• "Para lang sa malalaking app ang rate limiting." Target din ang maliliit na app, dahil ini-scan ng mga bot ang buong internet para sa bukas na form at AI endpoint. Hindi nakadepende sa laki mo ang gastos ng pang-aabuso.
• "Sapat na ang pagtatago ng button." Ang limitasyon sa browser ay pabor lamang, hindi proteksyon. Dapat ipatupad ang totoong limitasyon sa server.
• "Laging patas ang per-IP na limitasyon." Maraming tao ang maaaring magbahagi ng iisang IP address — isang opisina, paaralan, o mobile network. Mas patas ang per-user na limitasyon kapag naka-sign in na ang mga tao.
• "Ibig sabihin ng 429 ay sira ang serbisyo." Ibig sabihin nito ay masyado mo itong tinatawagan. Suriin ang code mo para sa mga loop, at i-cache ang mga resultang bihirang magbago — tingnan ang ano ang caching.
• "Pumapalit ang rate limiting sa spending cap." Gamitin ang dalawa. Maaaring may bug ang mga limitasyon sa app mo; ang spending cap ng provider ang iyong backstop.

Ano ang itatanong sa AI builder mo

• "Magdagdag ng server-side rate limiting sa login, sign-up, password reset, at sa AI endpoint. Magmungkahi ng makatwirang limitasyon."
• "Limitahan ang bawat naka-sign in na user sa [N] AI request bawat oras, at magpakita ng malinaw na mensahe na may oras ng paghihintay kapag naabot na ito."
• "Kapag nagbalik ng 429 ang outside API, mag-retry nang may exponential backoff hanggang 3 beses, saka magpakita ng magiliw na error."
• "Saan naka-store ang mga rate-limit counter? Gagana pa ba ang mga ito kapag tumakbo ang app sa higit sa isang makina?"
• "I-log tuwing may user o IP na naabot ang limitasyon, para matukoy ko ang pang-aabuso."
• "Aling mga outside service ang tinatawagan ng app na ito, at ano ang rate limit nila?"

Rate limiting sa Mythex

Malinaw ang mga docs ng Mythex tungkol dito para sa mga AI feature: ang rate limits, safety, at cost controls sa mga app na ginagawa mo ay sa iyo ang pagdidisenyo — tingnan ang Build an AI app. Hilingin sa agent na magdagdag ng limitasyon sa parehong mensaheng humihingi ng feature. Sa Pro, maaaring tumakbo ang isang na-publish na serbisyo sa hanggang tatlong makina kapag mabigat ang trapiko (tingnan ang Hosting limits), kaya humingi ng mga counter na nasa database at hindi sa memory ng iisang server.

Kaugnay na babasahin: ano ang API, paano gumamit ng LLM APIs, at ang security checklist para sa mga app na gawa ng AI.

Mga tanong