Slovník pojmů

Rate limiting

Limituje tempo požadavků, ne důvěryhodnost klienta. Je to jedna provozní a bezpečnostní vrstva, nikoli náhrada autentizace či autorizace.

Stručná definice

Kolik práce může daná skupina začít za určitý čas.

Rate limiting počítá požadavky podle zvolené identity — například API klíče, uživatele, tenantu, endpointu nebo jejich kombinace — a při překročení pravidla je odmítne, odloží nebo zpomalí. Chrání databázi, veřejné API, login, nákladné exporty i integraci volající marketplace.

Nejde jen o obranu proti zneužití. Aplikace může jako klient používat vlastní limiter, aby nepřekročila cizí kvótu. Rozhodující je jasně definovat, co se počítá, komu limit patří, zda je povolen krátký burst a co se stane při nedostupnosti úložiště čítačů.

Použití

Pro ochranu i řízení tempa

Stejný princip slouží na příjmu vlastního API i při volání externí služby.

veřejné API podle API klíče, uživatele, tenantu a endpointu
přihlášení, reset hesla a jiné operace ohrožené automatizovanými pokusy
nákladný export, vyhledávání či generování reportu
řízení množství requestů vůči dopravci, marketplace nebo AI službě
omezování souběžných importů jako samostatné pravidlo vedle rychlosti

Praktický příklad

Synchronizace zásob do marketplace

Marketplace povolí omezený počet requestů za období pro každý obchod. Worker před voláním atomicky odečte token z bucketu podle účtu marketplace. Když token chybí, úlohu naplánuje na později místo těsné retry smyčky.

Pokud marketplace vrátí 429 s Retry-After, aplikace pro tento účet nové requesty nejméně do uvedeného času pozastaví. Ostatní účty a důležitější lokální práce pokračují. Zápis stále používá stabilní externí identitu, protože limiter neřeší duplicitní účinek po timeoutu.

Jak funguje

Od identity klienta k odpovědi 429

Rozhodnutí musí být v distribuované aplikaci atomické a srozumitelně sdělené klientovi.

Partition key Služba určí, komu se limit počítá. Samotná IP adresa často nestačí; hlavičkám proxy lze věřit jen za důvěryhodným reverzním proxy.
Politika Definuje okno, kapacitu, cenu operace, povolený burst a případně samostatný limit souběhu.
Atomické čítání Ve více instancích se kontrola i změna čítače provede v jednom sdíleném kroku, například v Redis s TTL.
Výsledek Pokud kvóta zbývá, request pokračuje. Jinak API obvykle vrátí 429 Too Many Requests nebo worker úlohu odloží.
Reakce klienta Klient respektuje Retry-After, rozloží další požadavky a neblokuje tím nesouvisející priority.

Důležité pojmy

Algoritmus určuje kompromis mezi přesností a kapacitou.

Není jeden algoritmus vhodný pro všechny endpointy.

Fixed a sliding window

Pevné okno je úsporné, ale na jeho hraně dovolí krátký dvojnásobný burst. Klouzavé okno je přesnější; log jednotlivých requestů stojí více paměti, čítačová aproximace je kompromis.

Token a leaky bucket

Token bucket postupně doplňuje tokeny a dovoluje omezený burst. Leaky bucket uvolňuje práci rovnoměrně; při frontování může zvýšit latenci.

429 a Retry-After

HTTP 429 oznamuje překročení platného limitu požadavků v daném čase. Retry-After může uvést nejdřívější další pokus; vlastní X-RateLimit hlavičky nejsou univerzální standard.

Rate, throttle, quota, concurrency

Rate omezuje tempo, throttle může provoz zpomalovat, kvóta vymezuje spotřebu za delší období a concurrency limit počet právě běžících drahých operací.

Vztah k podobným pojmům

Limit nepokrývá všechny typy ochrany.

Pravidlo je užitečné jen s vhodnou identitou, dohledem a dalšími bezpečnostními kontrolami.

Autentizace a autorizace: Říkají, kdo klient je a co smí. Limiter pouze omezuje tempo, i když může používat jejich identitu.
Retry: Klient po 429 nesmí požadavek okamžitě opakovat; má respektovat instrukci serveru a svou politiku.
Redis: Často poskytuje atomické čítače, expiraci a skriptování pro distribuovaný limiter; při výpadku je nutné mít vědomou fail-open nebo fail-closed politiku.
Debouncing: Na klientovi slučuje rychle po sobě jdoucí akce. Nechrání sdílenou kapacitu serveru jako rate limiting.

Výhody a omezení

Předvídatelnější kapacita, ne neprůstřelná obrana.

Přínosy

ochrana drahých operací a závislých služeb před špičkou
spravedlivější využití společné kapacity mezi tenanty
jasné chování klienta při překročení kvóty
řízení vlastních workerů vůči limitům externího API

Rizika

limit podle IP poškozuje legitimní uživatele za NATem
neatomický čítač ve více instancích pravidlo propustí
dlouhé frontování jen přesune problém do latence
příliš přísný globální limit může poškodit zákazníky i provoz

Hranice použití

Míra omezení patří ke konkrétnímu riziku.

Login, export a zápis do marketplace nemají stejnou cenu ani identitu klienta. Samostatné limity pro citlivé endpointy jsou čitelnější než jedno globální číslo. Zbývající kvóta je pouze vodítko: jiný paralelní request nebo vyšší úroveň pravidla může další volání stále odmítnout.

Rate limiting není plnohodnotná obrana proti DDoS ani náhrada WAF, ochrany hesel, validace nebo antifraud pravidel. Pomáhá řídit aplikační kapacitu, ale síťový útok se musí řešit i na infrastrukturních vrstvách.

Na co myslet

Pravidla musí být měřitelná a férová.

Limity jsou produktová i technická pravidla; klient musí vědět, co se stalo, a tým musí vidět jejich dopad.

jasně určený partition key a politika důvěry k proxy hlavičkám
atomická distribuovaná operace a pravidlo pro výpadek úložiště limiteru
oddělené limity pro kritické endpointy, tenanta a nákladnou operaci
429 s přiměřenou instrukcí pro další pokus
monitoring odmítnutí, backlogu a změn v chování klientů

Časté otázky

Co rate limiting znamená pro klienta

Je HTTP 429 totéž co 503?

Ne. 429 říká, že klient překročil limit. 503 znamená dočasnou nedostupnost služby; obě odpovědi mohou obsahovat Retry-After.

Má se limitovat jen podle IP adresy?

Obvykle ne. IP je doplňkový signál; pro API bývá přesnější klíč, uživatel, tenant či kombinace s endpointem.

Kdy použít token bucket?

Když služba snese omezený krátký burst a chce držet dlouhodobý průměr. Přesné klouzavé okno má jiné náklady a vlastnosti.

Je rate limiting bezpečnostní řešení?

Je jedna ochranná vrstva. Nenahrazuje autentizaci, autorizaci, WAF ani ochranu účtů a hesel.

Jak řídím integrační toky v praxi

Tempo volání navrhuji podle limitů služby a ceny chyby.

U API integrací řeším stránkování, kvóty, retry, idempotenci a provozní dohled nad neúspěšnými synchronizacemi.

Jak pracuji s API a integracemi Nezávazně probrat projekt