Limity szybkości, błędy 429 i podnoszenie poziomu
Zaktualizowano September 1, 2026 · pierwsza publikacja September 1, 2026
Gdy usługa zaczyna zwracać 429, odruchem jest potraktowanie tego jak incydentu dostępności: podnieść limit, przejść na wyższy poziom, dodać ponowne próby, przywrócić przepustowość. Czasem to słuszne. Jest to jednak też mechanizm, dzięki któremu błąd w pętli zamienia się w rachunek na pięć cyfr, bo właśnie usunięto jedyną rzecz, która go powstrzymywała.
Co naprawdę mówi 429
Oznacza, że system próbuje wydawać szybciej, niż pozwala jego przydział. Dzieje się tak z dwóch bardzo różnych powodów, które wymagają przeciwnych reakcji. Realny wzrost popytu — więcej użytkowników, premiera, szczyt sezonowy — oznacza, że limit jest rzeczywiście za niski, a jego podniesienie przynosi realne przychody. Niekontrolowane zachowanie — burza ponownych prób, agent w pętli, backfill bez ograniczenia, zestaw testów skierowany na klucze produkcyjne — oznacza, że limit robi dokładnie to, do czego służy.
Same wskaźniki błędów tych dwóch przypadków nie rozróżnią. Rozróżnia je koszt na jednostkę pracy: realny wzrost utrzymuje ten stosunek mniej więcej stały, gdy wolumen rośnie; niekontrolowane zachowanie go łamie, bo wydajemy znacznie więcej na ukończone zadanie niż wczoraj. Ten jeden wskaźnik powinien decydować o każdym podniesieniu poziomu.
Ponowne próby pogarszają sprawę po cichu
Naiwne ponawianie po 429 bez wykładniczego opóźnienia i jitteru zamienia jedno przekroczenie limitu w zsynchronizowaną burzę. Żądania, które się udają, są rozliczane; wiele z tych, które się nie udają, i tak zużyło przetwarzanie wejścia. Ponieważ ponowne próby zwykle są realizowane w bibliotece klienta, a nie w kodzie aplikacji, to wzmocnienie nie pojawia się w dokumentacji projektowej funkcji.
Stosuj limity świadomie
Ustawiaj własne limity poniżej limitów dostawcy, osobno dla każdego środowiska i funkcji, tak aby pierwszym pęknięciem był Twój limit i to Ty kontrolowałeś, co dzieje się dalej. Trzymaj środowiska nieprodukcyjne ściśle ograniczone: nieudany build testowy jest tani, ograniczona ścieżka klienta już nie. Alarmuj na podstawie wskaźnika koszt na zadanie, a nie tylko liczby błędów. A gdy podnosisz poziom, traktuj to jak decyzję o wydatkach z wyznaczonym właścicielem, bo tym właśnie jest.
Powiązane
Powiązane
Chcesz zastosować to w swoim stosie? Przynieś faktury dostawców, logi bramy i najważniejsze przepływy pracy; wskażemy czynniki kosztów i ścieżkę oszczędności. Umów bezpłatny audyt →