Rate limiting

Kbelík pojme N žetonů, doplňuje se pevným tempem a každý požadavek si jeden vezme; když je prázdný, požadavek se odmítne. Krátký náraz projde, trvalý příval ne — přesně tvar reálného provozu.

Klíčujte podle toho, co chráníte: IP u anonymního provozu, id uživatele u přihlášených, API klíč u partnerů. U přihlášených neklíčujte jen podle IP za firemním NATem, jinak jedna rušná kancelář vyčerpá limit pro všechny uvnitř.

Endpoint, který volá LLM, stojí peníze při každém požadavku, a smyčka ve frontendu nebo zvědavý návštěvník s cURL může spálit měsíční rozpočet za odpoledne. AI trasy neomezujte jen počtem požadavků, ale tolkeny nebo útratou na uživatele a den — jeden dlouhý prompt může stát jako sto krátkých.

Účet chraňte třikrát: limiterem v aplikaci, tvrdým limitem útraty u poskytovatele nastaveným pod vaší komfortní hranicí a alarmem na 70 % rozpočtu. Právě třetí vás zachrání, když se první dva nakonfigurovaly špatně.

Rate limiting je nejviditelnější ochrana, jakou můžete nasadit. Dávkový export, který legitimně nahrává 5 000 řádků, narazí na limit a zákazník nahlásí, že „systém nefunguje“. Zveřejněte limity, vracejte 429 s jasnou zprávou a Retry-After a důvěryhodným integracím nebo adminům dejte vyšší rozpočet.

Kde počítadla žijí, mění jejich význam. V paměti počítají pro každou instanci a při nasazení se resetují; v Redisu napříč instancemi, ale každý požadavek stojí síťový obrat. U produktu na jedné instanci bohatě stačí paměť, klidně měsíce.