Ograniczanie ruchu dla publicznych API: praktyczne limity, kwoty i procedury blokowania

Jakiego problemu właściwie rozwiązuje ograniczanie ruchu

Ograniczanie ruchu w publicznych API nie ma na celu karania użytkowników. To zawór bezpieczeństwa, który utrzymuje dostępność usługi, gdy ruch robi się dziwny — czy to z powodu złośliwości, czy błędu klienta.

„Nadużycie” często wygląda na normalne na początku: scraper, który przegląda każdy endpoint, by skopiować dane; próby bruteforce logowania; wstrzykiwanie tokenów w trasach uwierzytelniania; albo klient, który wpadł w pętlę i powtarza żądanie co chwilę po timeoutcie. Czasem nikt w ogóle cię nie atakuje — aktualizacja aplikacji mobilnej trafia z błędnym regułami cache i nagle każde urządzenie pyta API co sekundę.

Zadanie jest proste: chronić dostępność i kontrolować koszty, nie blokując prawdziwych użytkowników wykonujących normalną pracę. Jeśli backend jest rozliczany (obliczenia, baza danych, email/SMS, wywołania AI), jeden głośny aktor może szybko zamienić się w naprawdę wysoką fakturę.

Samo ograniczanie ruchu to za mało. Bez monitoringu i jasnych odpowiedzi błędów dostaniesz ciche awarie, zagubionych klientów i zgłoszenia do supportu w stylu „wasze API jest nieaktywne”, choć w rzeczywistości działa throttling.

Kompletne zabezpieczenie zwykle składa się z kilku elementów:

• Limity szybkości: krótkookresowe ograniczenia (na sekundę/minutę), które powstrzymują skoki.
• Kwoty: dłuższe budżety (na dzień/miesiąc), które utrzymują przewidywalność użycia.
• Blokady: tymczasowe blokady dla jednoznacznie nadużywających wzorców.
• Wyjątki: allowlisty dla zaufanych integracji, narzędzi wewnętrznych lub VIP-ów.

Jeśli budujesz backend API na platformie takiej jak AppMaster, te zasady wciąż są ważne. Nawet przy czystym, generowanym kodzie chcesz mieć domyślne zabezpieczenia, żeby jeden zły klient nie zabił całej usługi.

Podstawowe pojęcia: limity, kwoty, throttling i blokady

Te terminy bywają mieszane, ale rozwiązują różne problemy i są inaczej odczuwalne przez użytkowników.

Limit szybkości, kwota i współbieżność: co każdy z nich oznacza

Limit szybkości to ograniczenie prędkości: ile żądań klient może wykonać w krótkim oknie (na sekundę, na minutę). Kwota to budżet: całkowite użycie w dłuższym okresie (na dzień, na miesiąc). Limit współbieżności restrykcyjnie ogranicza, ile żądań może być w trakcie realizacji jednocześnie — przydatne dla kosztownych endpointów nawet gdy tempo żądań wygląda normalnie.

Gdzie przypniesz limit, ma znaczenie:

• Na IP: proste, ale kara za to pada na współdzielone sieci (biura, szkoły, operatorzy mobilni).
• Na użytkownika: dobre dla aplikacji z logowaniem, ale zależy od wiarygodnej tożsamości.
• Na klucz API: powszechne w publicznych API, jasne przypisanie odpowiedzialności i łatwe do zakomunikowania.
• Na endpoint: użyteczne, gdy jedna ścieżka jest znacznie cięższa niż inne.

Throttling vs blokowanie i gdzie pasują blokady

Miękki throttling spowalnia klienta (opóźnienia, mniejsza możliwość burstu), dzięki czemu może się odzyskać bez psucia workflowów. Twarde blokowanie odrzuca żądania natychmiast, zwykle z HTTP 429.

Blokada jest silniejsza niż zwykły 429. 429 mówi „spróbuj ponownie wkrótce”. Blokada mówi „zatrzymaj się, dopóki nie zostanie spełniony jakiś warunek” — np. okres karencji, przegląd ręczny lub reset klucza. Zarezerwuj blokady dla jasnych sygnałów nadużyć (credential stuffing, agresywne scrapowanie, powtarzające się błędne uwierzytelnienia), a nie dla normalnych skoków ruchu.

Jeśli budujesz API narzędziem takim jak AppMaster, traktuj te mechanizmy osobno: krótkookresowe limity na piki, dłuższe kwoty dla kontroli kosztów i blokady tylko przy powtarzającym się złym zachowaniu.

Wybieranie praktycznych limitów bez dzikich zgadywań

Dobre limity zaczynają się od jednego celu: chronić backend, pozwalając normalnym użytkownikom dokończyć pracę. Nie potrzebujesz idealnych liczb od pierwszego dnia. Potrzebujesz bezpiecznej bazy i możliwości jej regulacji.

Prosty punkt startowy to limit na klucz API dopasowany do rodzaju Twojego API:

• Niski ruch: 60–300 żądań na minutę na klucz
• Średni ruch: 600–1 500 żądań na minutę na klucz
• Wysoki ruch: 3 000–10 000 żądań na minutę na klucz

Następnie rozdziel limity według typu endpointu. Odczyty są zwykle tańsze i mogą mieć wyższe limity. Operacje zapisujące zmieniają dane, często wywołują dodatkową logikę i zasługują na ostrzejsze limity. Powszechny schemat to np. 1 000/min dla GET, ale 100–300/min dla POST/PUT/DELETE.

Zidentyfikuj też kosztowne endpointy i traktuj je osobno: wyszukiwanie, generowanie raportów, eksporty, przesyłanie plików i wszystko, co uderza w wiele tabel lub uruchamia ciężką logikę biznesową, powinno mieć mniejszy bucket nawet jeśli reszta API jest hojna. Jeśli backend używa wizualnych workflowów (np. Business Process flows), każdy dodatkowy krok to realna praca, która przy obciążeniu się mnoży.

Plan na piki: dwa okna czasowe — krótkie do wchłonięcia szybkich skoków i dłuższe by kontrolować utrzymany ruch. Popularna kombinacja to 10 sekund plus 10 minut. Pozwala to użytkownikom, którzy klikają szybko, bez dawania scrapersom nieograniczonej prędkości.

Na koniec zdecyduj, co się stanie, gdy klient przekroczy limit. Większość publicznych API zwraca HTTP 429 z jasnym czasem ponowienia. Jeśli praca może być opóźniona (np. eksport), rozważ kolejkowanie zamiast ostrych blokad, aby prawdziwi użytkownicy nadal otrzymywali wyniki.

Projektowanie kwot na klucz, które wydają się uczciwe

Kwoty na klucz są zwykle najuczciwsze, bo odpowiadają temu, jak klienci rzeczywiście korzystają z usługi: jedno konto, jeden klucz API, jasna odpowiedzialność. Limity na IP wciąż są przydatne, ale często krzywdzą niewinnych użytkowników.

Współdzielone IP to główny problem. Całe biuro może wychodzić przez jedno publiczne IP, a operatorzy mobilni mogą umieszczać tysiące urządzeń za małą pulą IP. Jeśli polegasz na limitach na IP, jeden głośny użytkownik może spowolnić wszystkich. Polityka na klucz API unika tego, a lekkie ograniczenie na IP można zostawić jako backstop na oczywiste ataki.

Aby kwoty wydawały się uczciwe, powiąż je z poziomami klienta, nie zamykając jednocześnie nowych użytkowników. Klucz darmowy lub trial powinien pozwalać na realne testy, ale nie na skalę, która ci szkodzi. Prosty wzorzec to hojne bursty, umiarkowane tempo utrzymane i dzienna kwota dopasowana do planu.

Polityka na klucz, która pozostaje przewidywalna:

• Pozwól na krótkie bursty (ładowania stron, importy), potem egzekwuj stałe tempo.
• Dodaj dzienny limit na klucz, aby ograniczyć scrapowanie i zapętlone pętle.
• Podnoś limity w zależności od planu, ale zachowaj tę samą strukturę, by zachowanie było spójne.
• Stosuj niższy limit dla świeżo utworzonych kluczy, aby budowały historię.
• Trzymaj mały limit na IP, by łapać oczywiste fale i źle skonfigurowanych klientów.

By zniechęcić do dzielenia się kluczami i automatycznych rejestracji, nie potrzebujesz intensywnego nadzoru. Zacznij od prostych kontroli, np. nietypowe zmiany geolokalizacji, zbyt wiele różnych IP na godzinę dla jednego klucza albo wiele nowych kluczy tworzonych z tego samego źródła. Najpierw zaznacz i spowolnij; zablokuj dopiero po powtarzających się sygnałach.

Ruch anonimowy to miejsce, gdzie warto stosować ostrzejsze limity. Jeśli oferujesz klucze trial, limituj je mocniej i wymagaj podstawowej weryfikacji zanim podniesiesz limity. Jeśli twoje API obsługuje publiczny formularz, rozważ oddzielny anonimowy endpoint z własną kwotą, by reszta backendu była chroniona.

Jeśli budujesz API w AppMaster, logika na klucz jest łatwiejsza do utrzymania w spójny sposób, bo auth, reguły biznesowe i obsługa odpowiedzi są w jednym miejscu.

Przyjazne dla klienta odpowiedzi i nagłówki (żeby użytkownicy mogli się odzyskać)

Ograniczanie ruchu działa długofalowo tylko wtedy, gdy klienci rozumieją, co się stało i co mają zrobić dalej. Celuj w odpowiedzi nudno przewidywalne: ten sam status, te same pola, to samo znaczenie na wszystkich endpointach.

Gdy klient trafi na limit, zwróć HTTP 429 (Too Many Requests) z jasnym komunikatem i konkretnym czasem oczekiwania. Najszybszy zysk to dodanie Retry-After, bo nawet proste klienty potrafią się wtedy poprawnie zatrzymać.

Mały zestaw nagłówków czyni limity samoopisującymi. Trzymaj nazwy spójne i dołączaj je zarówno do odpowiedzi sukcesu (aby klienci mogli się dostosować), jak i do 429 (by mogli się odzyskać):

• Retry-After: sekundy do ponowienia
• X-RateLimit-Limit: dozwolone żądania w bieżącym oknie
• X-RateLimit-Remaining: pozostające żądania w bieżącym oknie
• X-RateLimit-Reset: kiedy okno się zresetuje (sekundy epoch lub czas ISO)
• X-RateLimit-Policy: krótki tekst, np. "60 requests per 60s"

Uczyń ciało błędu tak ustrukturyzowanym, jak odpowiedzi sukcesu. Powszechny wzorzec to obiekt błędu ze stabilnym code, przyjaznym message i wskazówkami odzyskania.

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Too many requests. Please retry after 12 seconds.",
    "retry_after_seconds": 12,
    "limit": 60,
    "remaining": 0,
    "reset_at": "2026-01-25T12:34:56Z"
  }
}

Powiedz klientom, jak mają się wycofywać po zobaczeniu 429. Domyślnie dobry jest backoff wykładniczy: zacznij od 1s, potem 2s, 4s i nakładaj limit (np. 30–60 sekund). Bądź też jawny co do momentu zaprzestania retryów.

Unikaj niespodzianek blisko kwot. Gdy klucz jest bliski limitu (np. 80–90% zużycia), dołącz pole ostrzegawcze lub nagłówek, aby klienci mogli zwolnić przed rozpoczęciem błędów. To ważne, gdy jeden skrypt może szybko uderzyć w wiele tras i spalić budżet szybciej niż się spodziewano.

Krok po kroku: prosty plan wdrożenia limitów i kwot

Wdrożenie działa najlepiej, gdy traktujesz limity jako zachowanie produktu, a nie jednorazową regułę zapory. Cel pozostaje ten sam: chronić backend przy zachowaniu pracy normalnych klientów.

Zacznij od szybkiego spisu. Wypisz każdy endpoint, a potem oznacz go według kosztu (CPU, praca w bazie, wywołania zewnętrzne) i ryzyka (logowanie, reset hasła, wyszukiwanie, upload). To zapobiega stosowaniu jednego twardego limitu wszędzie.

Kolejność wdrożenia, która zwykle unika niespodzianek:

• Oznacz endpointy według kosztu i ryzyka, i zdecyduj, które wymagają ostrzejszych reguł (logowanie, eksporty zbiorcze).
• Wybierz klucze tożsamości w priorytecie: najpierw klucz API, potem id użytkownika, a IP tylko jako fallback.
• Dodaj limity krótkookresowe (co 10 sekund lub na minutę) żeby zatrzymać piki i skrypty.
• Dodaj dłuższe kwoty (na godzinę lub dzień) żeby ograniczyć utrzymany ruch.
• Dodaj allowlisty dla zaufanych systemów i narzędzi wewnętrznych, żeby prace operacyjne nie były blokowane.

Pierwsze wydanie trzymaj konserwatywne. Łatwiej poluzować później niż odblokować rozzłoszczonych użytkowników.

Monitoruj i stroń, potem wersjonuj swoją politykę. Śledź ile żądań trafia na limity, które endpointy je wywołują i ile unikalnych kluczy jest objętych. Zmiany traktuj jak zmianę API: dokumentuj, wdrażaj stopniowo i trzymaj stare i nowe reguły rozdzielone, by móc szybko się wycofać.

Jeśli budujesz API z AppMaster, planuj te reguły razem z endpointami i logiką biznesową, żeby limity odpowiadały rzeczywistemu kosztowi każdego workflowu.

Procedury blokowania, które zatrzymują nadużycia bez dramatu

Blokady są jak pasy bezpieczeństwa. Powinny szybko zatrzymać oczywiste nadużycia, ale dawać normalnym użytkownikom jasną ścieżkę odzyskania, gdy coś pójdzie nie tak.

Spokojne podejście to progresywne kary. Zakładaj, że klient może być źle skonfigurowany, a nie złośliwy, i eskaluj tylko jeśli wzorzec się powtarza.

Prosta drabinka progresywna

Użyj małego zestawu kroków, które łatwo wyjaśnić i zaimplementować:

• Ostrzeżenie: powiedz klientowi, że zbliża się do limitów i kiedy nastąpi reset.
• Spowolnienie: dodaj krótkie opóźnienia lub ostrzejsze limity na sekundę dla danego klucza.
• Tymczasowa blokada: blokada na minuty (nie godziny) z dokładnym czasem odblokowania.
• Dłuższa blokada: dopiero po powtarzających się skokach w wielu oknach czasowych.
• Przegląd ręczny: dla wzorców wyglądających na celowe lub powracające.

Wybór, co blokować, ma znaczenie. Najuczciwsze jest zazwyczaj blokowanie po kluczu API, bo celuje w dzwoniącego, a nie w wszystkie osoby za współdzieloną siecią. Poziom konta pomaga, gdy użytkownicy rotują klucze. IP przydaje się dla anonimowego ruchu, ale powoduje fałszywe trafienia przy NATach, biurach i operatorach mobilnych. Przy poważnym nadużyciu łącz sygnały (np. zablokuj klucz i wprowadź dodatkowe checks dla tego IP), ale trzymaj mały zasięg szkód.

Ustal blokady czasowe z prostymi regułami: „zablokowany do 14:05 UTC” i „reset po 30 minutach poprawnego zachowania”. Unikaj stałych banów dla systemów automatycznych. Błędny klient może wpaść w pętlę i szybko przepalić limity, więc projektuj kary z zanikiem w czasie. Utrzymany okres niskiej aktywności powinien zmniejszyć poziom kary.

Jeśli budujesz swoje API w AppMaster, ta drabinka dobrze mapuje się na przechowywane liczniki i Business Process, który decyduje: zezwól, spowolnij lub zablokuj, i zapisuje czas odblokowania dla klucza.

Dla powtarzających się sprawców trzymaj ścieżkę przeglądu ręcznego. Nie kłóć się z użytkownikami. Poproś o ID żądań, znaczniki czasu i nazwę klucza, potem zdecyduj na podstawie dowodów.

Typowe błędy powodujące fałszywe trafienia

Fałszywe trafienia to sytuacje, gdy obrona blokuje normalnych użytkowników. Zwykle dzieje się tak, gdy reguły są zbyt proste względem rzeczywistego użycia API.

Klasyczny błąd to jeden globalny limit dla wszystkiego. Jeśli traktujesz tani endpoint do odczytu i kosztowny eksport tak samo, albo nadmiernie chronisz tani endpoint (irytujące), albo nie chronisz ciężkiego (niebezpieczne). Rozdziel limity według kosztu i spraw, by ciężkie ścieżki były ostrzejsze.

Limitowanie tylko po IP to kolejna pułapka. Wielu realnych użytkowników dzieli jedno publiczne IP (biura, szkoły, operatorzy mobilni). Jeden ciężki użytkownik może zablokować całe środowisko i wyglądać to jak losowe awarie. Preferuj limity po kluczu API, a IP używaj jako sygnał pomocniczy.

Awaria systemu limiterów też może dawać fałszywe trafienia. Jeśli magazyn limiterów padnie, „fail closed” może zabrać całe API. „Fail open” może zaprosić skok, który i tak zniszczy backend. Wybierz jasny fallback: trzymaj mały awaryjny cap na krawędzi i degradowanie niekrytycznych endpointów.

Obsługa po stronie klienta ma większe znaczenie niż większość zespołów sądzi. Jeśli zwracasz ogólny 429 bez jasnego komunikatu, użytkownicy będą retryować mocniej i wywołają więcej blokad. Zawsze wysyłaj Retry-After i podawaj specyficzny tekst błędu (np. „Too many requests for this key. Try again in 30 seconds.”).

Najbardziej uniknionym problemem jest sekretność. Ukryte limity wyglądają jak błędy, gdy klienci trafiają na nie pod produkcyjnym obciążeniem po raz pierwszy. Podziel się prostą polityką i trzymaj ją stabilną.

Krótka lista kontrolna, by unikać fałszywych trafień:

• Oddzielne limity dla drogich vs tanich endpointów
• Główne ograniczanie po kluczu API, nie tylko po IP
• Zdefiniowane zachowanie przy niedostępności limiterów
• Jasne odpowiedzi 429 z Retry-After
• Limity udokumentowane i zakomunikowane przed egzekucją

Jeśli budujesz API z narzędziem takim jak AppMaster, zazwyczaj oznacza to ustawienie różnych capów per endpoint i zwracanie spójnych payloadów błędów, by klienci mogli się wycofać bez zgadywania.

Monitoring i alertowanie, które naprawdę pomaga

Ograniczanie ruchu działa tylko wtedy, gdy widzisz, co się dzieje w czasie rzeczywistym. Cel to nie złapać każdy skok, lecz dostrzec wzorce prowadzące do outage'ów lub wściekłych użytkowników.

Zacznij od małego zestawu sygnałów, które wyjaśniają zarówno wolumen, jak i intencję:

• Żądania na minutę (ogółem i per klucz API)
• Wskaźnik 429 (throttled) i 5xx (ból backendu)
• Powtarzające się 401/403 (błędne klucze, credential stuffing, źle skonfigurowani klienci)
• Top endpointów według wolumenu i kosztu (wolne zapytania, ciężkie eksporty)
• Nowe lub niespodziewane endpointy pojawiające się w top 10

Aby odróżnić „zły ruch” od „wypuściliśmy coś”, dodaj kontekst do dashboardów: czas deployu, zmiany feature flag, wysyłki marketingowe. Jeśli ruch skacze tuż po release i miks 429/5xx jest zdrowy, to zwykle wzrost, nie atak. Jeśli skok jest skoncentrowany w jednym kluczu, zakresie IP lub jednym ciężkim endpointzie — traktuj to jako podejrzane.

Alerty powinny być nudne. Używaj progów plus cooldownów, by nie być wzywanym co minutę na to samo zdarzenie:

• 429 powyżej X% przez 10 minut — powiadom raz na godzinę
• 5xx powyżej Y% przez 5 minut — natychmiast paginuj
• Pojedynczy klucz przekracza kwotę o Z% przez 15 minut — otwórz śledztwo
• 401/403 powyżej N/min — oznacz jako możliwe nadużycie

Gdy alarm się uruchomi, zachowaj krótką notatkę incydentu: co się zmieniło, co zaobserwowano (top klucze/endpointy) i co dostosowano (limity, cache, tymczasowe blokady). Z czasem te notatki stają się twoim prawdziwym playbookiem.

Przykład: uruchamiasz nowy endpoint wyszukiwania i ruch się podwaja. Jeśli większość wywołań trafia w ten endpoint z wielu kluczy, podnieś nieco kwotę per klucz i zoptymalizuj endpoint. Jeśli jeden klucz ciągle robi eksporty i podnosi latencję, nałóż oddzielny cap na ten endpoint i skontaktuj się z właścicielem.

Krótka lista kontrolna: sanity checks przed i po uruchomieniu

Dobre ustawienia są nudne, gdy działają. Ta lista łapie problemy, które zwykle powodują fałszywe trafienia lub zostawiają oczywiste luki.

Zanim wypuścisz nowy endpoint

Przetestuj w staging i znów zaraz po uruchomieniu:

• Tożsamość: potwierdź, że limiter bazuje na właściwym kluczu (najpierw klucz API, potem user lub IP jako fallback) i że rotowane klucze nie dziedziczą starych kar.
• Limity: ustaw domyślną kwotę na klucz, potem dopasuj według kosztu endpointu (tani odczyt vs drogi zapis) i oczekiwanych burstów.
• Odpowiedzi: zwracaj jasny status i informacje o odzyskaniu (czas retry, pozostały budżet, stabilny kod błędu).
• Logi: zapisuj kto został ograniczony (klucz/user/IP), która trasa, jaka reguła zadziałała i request ID dla supportu.
• Bypass: trzymaj emergency allowlistę dla monitorów i zaufanych integracji.

Jeśli budujesz na AppMaster, traktuj każdy nowy endpoint jako decyzję o poziomie kosztu: proste wywołanie może być hojne, podczas gdy cokolwiek uruchamia ciężką logikę biznesową powinno zaczynać konserwatywnie.

Gdy zdarzy się incydent (nadużycie lub nagły ruch)

Chroń backend, pozwalając jednocześnie realnym użytkownikom się odzyskać:

• Podnoś limity tymczasowo tylko dla najmniej ryzykownych tras (często odczyty) i obserwuj wskaźniki błędów.
• Dodaj krótką allowlistę dla znanych dobrych klientów podczas dochodzenia.
• Zaostrz konkretne ryzykowne trasy zamiast obniżać globalne limity.
• Włącz silniejszą identyfikację (wymagaj kluczy API, zmniejsz zależność od IP), aby uniknąć blokowania współdzielonych sieci.
• Zbierz próbki: top klucze, top IP, user agenty i dokładne wzorce payloadów.

Zanim podniesiesz limity dla klienta, sprawdź jego normalny wzorzec żądań, miks endpointów i czy może zbatchować albo dodać backoff. Potwierdź też, że nie dzieli jednego klucza między wiele aplikacji.

Co miesiąc przeglądaj: top ograniczane endpointy, procent ruchu trafiającego na limity, nowe drogie trasy i czy twoje kwoty nadal pasują do realnego użycia.

Przykładowy scenariusz: ochrona rzeczywistego publicznego API bez łamania użytkowników

Wyobraź sobie, że prowadzisz publiczne API używane przez dwie aplikacje: portal klienta (duży, stały ruch) i wewnętrzne narzędzie admina (niewielki ruch, ale silne akcje). Obie używają kluczy API, a portal ma też endpoint logowania dla użytkowników końcowych.

Pewnego popołudnia partner wypuszcza wadną integrację. Zaczyna retryować nieudane żądania w ciasnej pętli, wysyłając 200 żądań na sekundę z jednego klucza API. Bez zabezpieczeń ten klucz może zagłuszyć wszystkich innych.

Limity per-key ograniczają zasięg szkód. Wadliwy klucz dochodzi do swojego capu minutowego, dostaje 429 i reszta klientów działa dalej. Możesz też mieć oddzielny, niższy limit dla kosztownych endpointów (np. eksporty), więc nawet „dozwolony” ruch nie zaciąży bazy danych.

Równocześnie próba bruteforce logowania zaczyna uderzać w endpoint auth. Zamiast blokować cały zakres IP (co mogłoby uderzyć w realnych użytkowników za NAT), spowalniasz to i potem blokujesz na podstawie zachowania: zbyt wiele nieudanych prób na konto plus na IP w krótkim oknie. Atakujący dostaje coraz dłuższe przerwy, potem tymczasową blokadę.

Prawdziwy klient, który kilka razy źle wpisał hasło, może się odzyskać, bo twoje odpowiedzi są jasne i przewidywalne:

• 429 z Retry-After, więc klient wie kiedy spróbować ponownie
• Krótka blokada (np. 10–15 minut), nie stały ban
• Spójne komunikaty błędów, które nie ujawniają, czy konto istnieje

Aby potwierdzić naprawę, obserwujesz metryki:

• 429 według klucza API i endpointu
• Wskaźnik nieudanych logowań i liczba blokad
• P95 latencji i CPU bazy w trakcie incydentu
• Liczba unikalnych kluczy objętych (powinna być mała)

To wygląda jak ochronne ograniczanie ruchu, które osłania backend bez karania normalnych użytkowników.

Następne kroki: wprowadź małą politykę i iteruj

Nie potrzebujesz doskonałego modelu od pierwszego dnia. Zacznij od małej, jasnej polityki i udoskonalaj ją, obserwując, jak zachowują się realni użytkownicy.

Solidna pierwsza wersja zwykle ma trzy części:

• Bazę per-key (żądania na minutę) pokrywającą większość endpointów
• Ostrzejsze capy na kosztowne endpointy (wyszukiwanie, eksporty, uploady, złożone raporty)
• Jasne odpowiedzi 429 z krótką wiadomością mówiącą klientom, co robić dalej

Dodawaj blokady tylko tam, gdzie ryzyko nadużyć jest wysokie i intencję da się łatwo wywnioskować. Typowe kandydaty to rejestracja, logowanie, reset hasła i tworzenie tokenów. Na początku trzymaj blokady krótkie (minuty, nie dni) i preferuj progresywną frykcję: najpierw spowolnienie, potem tymczasowa blokada, a potem mocniejsza weryfikacja.

Opisz politykę prostym językiem, żeby support mógł ją wyjaśnić bez pomocy inżynierii. Uwzględnij co jest limitowane (per klucz API, per IP, per konto), okno resetu i jak klient może się odzyskać.

Jeśli implementujesz to przy budowie nowego backendu, AppMaster może być praktycznym wyborem: możesz tworzyć API, definiować workflowy biznesowe (w tym liczniki i decyzje blokowania) wizualnie, a potem wdrażać w chmurze lub eksportować wygenerowany kod, gdy potrzebujesz pełnej kontroli.