Rate limit

Čo je rate limit a prečo existuje

Rate limit je politika poskytovateľa API, ktorá obmedzuje počet požiadaviek (alebo spracovaných jednotiek, napr. tokenov) v definovanom časovom intervale. Cieľom je chrániť infraštruktúru, zabezpečiť férové zdieľanie kapacity medzi klientmi, udržať predvídateľnú latenciu a kontrolovať náklady. V kontexte AIO/AEO a moderného SEO je riadenie limitov kľúčové najmä pri práci s LLM API, vyhľadávacími API, indexačnými službami a pri zbere či synchronizácii obsahových dát.

Typy rate limitov a metriky

• Počet požiadaviek (requests/min, requests/sec).
• Toky jednotiek (napr. tokens per minute, rows per hour).
• Súbežnosť (concurrency): max. počet paralelných spojení/úloh.
• Okno (window): fixné (napr. 60 s), posuvné (sliding), alebo tokové modely (bucket).
• Dimenzia limitu: per kľúč, per IP, per účet/organizáciu, per koncový používateľ (sub-kvóty).

Bežné algoritmy: ako sa rate limit aplikuje

• Fixed window: jednoduchý „reset“ počítadla každé T sekúnd. Výhoda: jednoduchosť. Nevýhoda: „hraničné nárazy“ na prelome okien.
• Sliding window: presnejšie rozdelenie záťaže naprieč plynúcim intervalom; menej burstov.
• Leaky bucket (odkvapkávanie): požiadavky odtekajú konštantnou rýchlosťou; vyrovnáva špičky.
• Token bucket: do „vedra“ pribúdajú tokeny rýchlosťou R/s; požiadavka tokeny spotrebuje. Umožňuje zdravé bursty až po kapacitu vedra.
• Concurrency gate: tvrdý limit na počet súbežných spracovaní; dopĺňa tokové limity.

Signály z odpovedí API

• HTTP 429 Too Many Requests: prekročený limit, dočasne spomaliť.
• HTTP 503 Service Unavailable: preťaženie; často vhodné skúsiť opakovanie s backoff.
• Hlavičky: Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset (názvy sa líšia podľa poskytovateľa).

Exponenciálny backoff a jitter: odporúčaný postup

• Exponenciálny backoff: 1 s → 2 s → 4 s → 8 s (max. strop) pri 429/503, s rešpektovaním Retry-After.
• Full jitter: náhodný rozptyl v intervale [0, aktuálne_oneskorenie] na predídenie synchronizovaných nárazov viacerých klientov.
• Idempotencia: používať idempotentné operácie alebo Idempotency-Key pre bezpečné opakovania.

Rate limit a LLM: RPM, TPM a súbežnosť

LLM API často používajú kombinované limity – napr. requests per minute (RPM) a tokens per minute (TPM), plus concurrency. Skutočný priepustnostný strop je minimum zo všetkých aktívnych limitov.

• Príklad výpočtu: limit je 60 RPM a 120k TPM. Priemerne spotrebujete 1,5k tokenov/požiadavku. Maximálne RPM podľa TPM je floor(120000 / 1500) = 80. Efektívny strop je min(60, 80) = 60 RPM.
• Optimalizácia: znížením priemernej dĺžky promptu/odpovede (tokenová ekonomika) zvýšite dostupné RPM v rámci TPM limitu.
• Batching a kompozícia: menej volaní s rozumnou agregáciou, alebo streaming na skoršie UX signály bez zmeny TPM.

Architektúra klienta: ako sa vyhnúť 429

• Client-side throttling podľa známeho limitu (token bucket v aplikácii).
• Fronta požiadaviek s prioritami (dôležité dopyty AEO/produkcia vs. nízkoprioritné dávky).
• Worker pool s limitom súbežnosti a adaptívnym riadením rýchlosti (meranie latencie a chýb → úprava R/s).
• Circuit breaker pri zhoršení chýb/latencie; half-open testy na obnovu.
• Cache a deduplikácia: identické dopyty obslúžiť z cache; „single flight“ zamedzí paralelným duplikátom.

Server-side stratégie a viacúrovňové kvóty

• Hierarchické kvóty: organizácia → projekt → API kľúč → koncový používateľ; férové zdieľanie.
• Burst capacity: väčšie vedrá pre krátke špičky s priemerným limitom cez sliding window.
• Admission control: „queuing + tokens“ alebo „fair queuing“ podľa priority a histórie využitia.
• Autoscaling: rýchle škálovanie workerov + ochranné limity, aby škálovanie nenarazilo na upstream stropy.

Rate limit vs. SEO/AEO pipeline

• Crawl & fetch: rešpektujte limity zdrojových API/webov; používajte If-None-Match (ETag) a If-Modified-Since.
• Indexačné dávky: časujte dávky, sledujte response hlavičky a dynamicky upravujte throughput.
• Obsahové generovanie s LLM: prerozdeľte kapacity medzi SERP-feature výstupy (FAQ, HowTo, Product) a dlhé články.
• Analógia s „crawl budget“: každé API má svoj „rozpočet“. Plánujte dotazy tak, aby najprv prinášali maximálny informačný zisk.

Etika, legálnosť a robots politika

• Rešpekt API TOS: nepoužívajte obchádzanie limitov (rotácia účtov/IP) – hrozí blokácia.
• Robotické štandardy: pri crawlovaní webov rešpektovať robots.txt a tarify požiadaviek; správne hlavičky User-Agent.
• Anti-spam: pozor na vysokofrekvenčné dopyty do vyhľadávacích polí a endpointov s verejným prístupom.

CDN, cache a „stale-while-revalidate“

Na zníženie potreby volaní do pôvodu:

• Edge cache pre časté GETy; krótsie TTL s stale-while-revalidate pre rýchlosť a úsporu limitov.
• Variantyzácia cache (Vary) podľa relevantných parametrov, aby nedochádzalo k cache missom.
• ETag/304: zníženie prenosov aj CPU; šetrí limity upstreamu.

Monitorovanie a observabilita

• Metriky: počet volaní, chybovosť (429/5xx), latencia p50/p95/p99, využitie kvót (remaining), dropy v klientskom throttle.
• Trace: korelácia požiadaviek a retry cyklov; identifikácia horúcich bodov.
• Alerty: pri poklese remaining < X%, pri špičkách latencie, pri náraste 429.
• Experimenty: canary release pre zmeny rýchlosti, A/B pre stratégiu backoff.

Výpočtové vzorce a kapacitné plánovanie

• Teoretické QPS: QPS = min(QPS_limit, concurrency / avg_latency).
• Tokenový strop (TPM): RPM_TPM = floor(TPM_limit / avg_tokens_per_request); efektívny RPM = min(RPM_limit, RPM_TPM).
• Šírka fronty: musí pokryť najväčší burst do času prvého spracovania, bez pretečenia vedra.

Vzorová politika klienta (pseudo-konfigurácia)

rateLimit: { window: 60s, rpm: 60, tpm: 120000, concurrency: 8 }
backoff: { type: "exponential", base: 1s, factor: 2, jitter: "full", max: 32s, maxRetries: 6 }
caching: { mode: "etag+ttl", ttl: 300s, staleWhileRevalidate: 30s }
queue: { priorities: ["prod", "batch"], maxLength: 5000 }
idempotency: { header: "Idempotency-Key" }
alerts: { remainingThreshold: 0.1, errorRate: 0.02, p95LatencyMs: 1500 }

Špecifiká pre pipelines v AIO/AEO

• Orchestrácia: rozdeľte pipeline na kroky (extrakcia → sumarizácia → validácia → publikácia) so samostatnými limitmi a medzipamäťou.
• Prioritizácia: odpovede pre užívateľov (AEO) majú vyššiu prioritu než offline dávky.
• Degradácia: pri preťažení použiť kratšie výstupy, nižšie teploty, alebo lacnejší model; plánovaný graceful fallback.

Testovanie a validácia

• Load test v hraniciach TOS s reálnymi promptami a veľkosťami odpovedí; sledujte RPM/TPM a chovanie backoffu.
• Chaos test: simulujte 429/503, náhodné výpadky, latenciu; overte circuit breaker a opakovania.
• Replay: idempotentné požiadavky prehrávajte na stagingu na overenie deterministickosti.

Časté chyby a ich riešenia

1. Ignorovanie hlavičky Retry-After → implementujte rešpektovanie a kombinujte s exponenciálnym backoffom.
2. Príliš vysoká súbežnosť → znížte pool size, rozložte dávky, zavádzajte bulkhead izoláciu.
3. Žiadna cache → implementujte ETag/TTL; deduplikujte rovnaké dotazy.
4. Neidempotentné retry → použite Idempotency-Key, alebo rozlíšte „read“ a „write“ operácie.
5. Statické limity → zaveďte adaptive throttling podľa reálnych metŕik a spätnej väzby API.

Checklist implementácie pre prax

• Zdokumentujte oficiálne limity (RPM, TPM, concurrency) a pravidlá retry.
• Nasadte klientsky token bucket + exponenciálny backoff s jitterom a rešpektom Retry-After.
• Zapnite cache (ETag/TTL) a deduplikáciu identických dotazov.
• Zaveďte frontu s prioritami, worker pool s limitom súbežnosti a circuit breaker.
• Merajte využitie kvót, p95 latenciu, 429/5xx, „remaining“; nastavte alerty.
• Pripravte degradáciu funkcií (kratšie výstupy, lacnejší model) pre špičky.

Zhrnutie

Rate limit je centrálna súčasť škálovateľného a spoľahlivého využívania API v modernom SEO, AIO a AEO. Spojením klientskych techník (throttling, backoff, cache, fronty), serverových mechanizmov (bucket, sliding window, admission control) a dôslednej observability dosiahnete stabilnú priepustnosť bez 429, predvídateľnú latenciu a lepšiu ekonomiku spotreby tokenov pri práci s LLM. Premyslené riadenie limitov je konkurenčnou výhodou celého obsahového aj odpoveďového ekosystému.