Korzystaj z rate limitów i mechanizmów throttle dla API i webhooków.

Stosowanie limitów żądań i mechanizmów throttle chroni API oraz webhooki przed przeciążeniem i nadużyciami.

Rate limiting jako kontrola ruchu do API

Rate limit określa, ile żądań klient może wysłać do interfejsu API w danym przedziale czasu. Limit może być przypisany do klucza API, użytkownika, adresu IP, aplikacji albo konkretnego zasobu. Pozwala ograniczyć zarówno przypadkowe przeciążenie usługi, jak i automatyczne wysyłanie nadmiernej liczby żądań. Sam limit nie zwiększa wydajności serwera, lecz kontroluje tempo napływu pracy do aplikacji, warstwy uwierzytelniania, bazy danych i usług zewnętrznych.

Przekroczenie limitu w API HTTP jest zwykle sygnalizowane kodem odpowiedzi 429 Too Many Requests. Serwer może dołączyć nagłówek Retry-After, wskazujący czas w sekundach albo konkretną datę, po której klient powinien ponowić żądanie. Dodatkowe nagłówki opisujące limit, pozostały budżet i moment odnowienia, takie jak RateLimit-Limit, RateLimit-Remaining oraz RateLimit-Reset, są stosowane przez część usług zgodnie z przyjętą polityką API; klient nie powinien zakładać ich obecności bez sprawdzenia dokumentacji danego interfejsu.

Throttle, burst i algorytmy egzekwowania limitu

Throttle jest mechanizmem ograniczającym tempo wykonywania operacji. W praktyce może opóźniać żądania, kolejkować je albo odrzucać po przekroczeniu ustalonego poziomu. Rate limit często opisuje dopuszczalną liczbę operacji, natomiast throttle określa sposób reagowania na zbyt szybki ruch. Oba mechanizmy mogą działać razem: klient otrzymuje określony budżet żądań, a kolejne operacje są spowalniane lub blokowane.

Często używane modele to token bucket i leaky bucket. W modelu token bucket pula tokenów jest uzupełniana ze stałą szybkością, a każde żądanie zużywa token; pojemność puli pozwala obsłużyć ograniczony burst, czyli krótkotrwały wzrost ruchu. W modelu leaky bucket operacje opuszczają kolejkę w kontrolowanym tempie, dzięki czemu przepływ jest bardziej równomierny. Implementacja może również stosować stałe okna czasowe, przesuwane okna czasowe albo licznik żądań utrzymywany w pamięci współdzielonej. Skuteczność limitu zależy od tego, czy wszystkie instancje aplikacji korzystają ze wspólnego stanu.

Ograniczanie dostarczania webhooków

Webhook jest żądaniem HTTP wysyłanym przez system źródłowy do adresu odbiorcy po wystąpieniu zdarzenia. Odbiorca powinien szybko potwierdzić przyjęcie poprawnego żądania, a cięższe przetwarzanie wykonać poza obsługą połączenia. Po stronie nadawcy throttle może ograniczać liczbę równoległych dostaw do jednego endpointu, tempo wysyłania zdarzeń albo liczbę ponowień po błędzie. Chroni to odbiorcę przed sytuacją, w której seria zdarzeń powoduje wyczerpanie puli połączeń, pamięci lub czasu procesora.

Webhooki wymagają obsługi błędów przejściowych i powtórzeń. Niedostępność endpointu, przekroczenie limitu czasu, odpowiedź z grupy 5xx albo odpowiedź 429 mogą uruchomić ponowienie zgodnie z polityką nadawcy. Bezpieczny odbiorca musi zakładać, że to samo zdarzenie może pojawić się więcej niż raz, dlatego przetwarzanie powinno być idempotentne. Pomaga w tym identyfikator zdarzenia zapisywany przed wykonaniem skutku biznesowego oraz sprawdzanie, czy dany identyfikator był już obsłużony. Ponowienia powinny używać backoffu, najlepiej z losowym rozproszeniem czasu, aby wiele klientów nie próbowało ponownie dokładnie w tej samej chwili.

Weryfikacja konfiguracji i diagnostyka przepływu żądań

Diagnostyka rate limitów zaczyna się od ustalenia, gdzie dokładnie następuje odrzucenie: w kliencie, bramie API, serwerze aplikacyjnym, reverse proxy czy u zewnętrznego dostawcy. Należy porównać metodę HTTP, ścieżkę, identyfikator klienta, kod odpowiedzi, nagłówki limitu, czas odpowiedzi i treść komunikatu błędu. W logach warto rozdzielić odpowiedzi 429 od błędów 401, 403, 408 i 5xx, ponieważ oznaczają odpowiednio ograniczenie tempa, problem z uwierzytelnieniem, brak uprawnień, przekroczenie czasu oczekiwania albo błąd po stronie usługi.

Po stronie klienta trzeba sprawdzić, czy kod obsługuje Retry-After, stosuje ograniczenie równoległości i nie wykonuje bezwarunkowych ponowień w pętli. Po stronie webhooka należy zweryfikować, czy odpowiedź sukcesu jest zwracana dopiero po poprawnym przyjęciu danych, czy identyfikator zdarzenia jest przechowywany oraz czy ponowne dostarczenie nie powoduje podwójnego zapisu lub podwójnej operacji. Analiza metryk powinna obejmować liczbę żądań, odsetek odpowiedzi 429, długość kolejek, liczbę ponowień, czas przetwarzania i liczbę aktywnych połączeń. Takie dane pozwalają odróżnić zbyt niski limit od rzeczywistego wycieku żądań, błędnej konfiguracji klienta lub powtarzającego się błędu endpointu.

Jeżeli ograniczenie ruchu zostało skonfigurowane niepoprawnie, naprawa polega na dopasowaniu limitu do rzeczywistego profilu pracy, ustawieniu kontrolowanego throttle oraz wdrożeniu bezpiecznego backoffu. Nie należy usuwać limitu bez analizy, ponieważ może to przenieść problem z warstwy API do bazy danych albo całkowicie zablokować obsługę webhooków. Przy serwisowaniu laptopów i komputerów PC można dodatkowo sprawdzić aplikację kliencką, jej logi, zadania w tle, konfigurację proxy i stan połączenia sieciowego, aby ustalić, czy nadmiarowe żądania wynikają z oprogramowania uruchomionego na danym urządzeniu.