brak limitu wysyłek

Brak limitu wysyłek to usterka procesowa umożliwiająca nieograniczoną liczbę kampanii kierowanych do odbiorców.

Brak limitu wysyłek jako błąd kontroli kampanii

Brak limitu wysyłek oznacza sytuację, w której system obsługujący kampanie nie nakłada skutecznego ograniczenia na liczbę wiadomości wysyłanych w określonym czasie. Limit może dotyczyć liczby odbiorców jednej kampanii, liczby kampanii uruchomionych przez konto, liczby komunikatów wysłanych w ciągu godziny albo całkowitego wolumenu przypisanego do konkretnego planu, użytkownika lub nadawcy. Jeżeli żadna z tych kontroli nie działa, aplikacja może przyjąć i przekazać do realizacji nieograniczoną liczbę zadań.

Nie jest to samo co wysoka przepustowość systemu. Przepustowość określa, ile wiadomości infrastruktura potrafi obsłużyć w jednostce czasu, natomiast limit wysyłek jest regułą administracyjną lub techniczną, która wyznacza dopuszczalny zakres działania. System może mieć sprawną kolejkę komunikatów, lecz nadal być pozbawiony kontroli liczby kampanii. W takim przypadku problem dotyczy logiki procesu, walidacji parametrów oraz egzekwowania zasad przed umieszczeniem kolejnych zadań w kolejce.

Gdzie powinno działać ograniczenie

Kontrola limitu powinna być wykonywana po stronie serwera lub innego centralnego komponentu zarządzającego wysyłką. Ograniczenie obecne wyłącznie w interfejsie użytkownika nie zapewnia ochrony, ponieważ żądanie można wysłać bezpośrednio do interfejsu programistycznego API, ponowić połączenie albo użyć innego klienta. Serwer powinien sprawdzić uprawnienia konta, aktualny licznik wykorzystania, planowany rozmiar kampanii oraz stan innych zadań należących do tego samego nadawcy.

W praktyce stosuje się licznik okresowy, limit całkowity, kolejkę z kontrolą tempa oraz mechanizm odrzucający żądanie po przekroczeniu wartości granicznej. Przydatne jest także rozdzielenie stanu „kampania utworzona” od stanu „kampania dopuszczona do wysyłki”. Samo zapisanie kampanii w bazie nie powinno automatycznie oznaczać zgody na jej wykonanie. Przed rozpoczęciem pracy kolejka powinna ponownie sprawdzić limit, aby kilka równoczesnych żądań nie ominęło kontroli przez wyścig między procesami.

Skutki braku kontroli w kolejce komunikatów

Nieograniczone przyjmowanie kampanii może doprowadzić do gwałtownego wzrostu liczby rekordów oczekujących na wysyłkę. Następstwem jest wydłużenie kolejki, większe zużycie procesora i pamięci, wzrost liczby połączeń z usługą dostarczającą wiadomości oraz opóźnienia w obsłudze innych zadań. Jeżeli aplikacja tworzy osobne zadanie dla każdego odbiorcy, jedna duża kampania może dodatkowo obciążyć bazę danych i mechanizmy blokad.

Diagnoza powinna obejmować historię utworzenia kampanii, identyfikator konta, liczbę odbiorców, moment przekazania zadania do kolejki, wynik walidacji oraz faktyczną liczbę prób wysyłki. W logach warto rozróżnić żądania zaakceptowane, odrzucone z powodu limitu, wstrzymane przez regulator tempa i ponowione po błędzie. Należy również sprawdzić, czy licznik jest zwiększany atomowo. Jeżeli aplikacja najpierw odczytuje bieżące zużycie, a dopiero później zapisuje nową wartość, równoległe żądania mogą wszystkie otrzymać zgodę na wysyłkę mimo przekroczenia limitu.

Sprawdzenie reguł, licznika i odpowiedzi aplikacji

Podczas analizy należy ustalić, czy limit jest zdefiniowany w konfiguracji, bazie danych, kodzie aplikacji czy po stronie zewnętrznego dostawcy wysyłki. Trzeba sprawdzić jednostkę pomiaru, długość okresu rozliczeniowego, sposób liczenia wiadomości nieudanych oraz zachowanie przy ponowieniu tego samego żądania. Istotna jest idempotencja: ponowne przesłanie identycznego żądania nie powinno utworzyć drugiej kampanii ani podwoić rezerwacji limitu.

Wynik przekroczenia powinien być jednoznaczny dla klienta aplikacji, na przykład przez odpowiedź HTTP 429 wraz z informacją o konieczności odczekania, jeżeli system korzysta z interfejsu HTTP. Sama odpowiedź o sukcesie bez faktycznego zarezerwowania limitu wskazuje na niespójność między warstwą API a kolejką. W komputerze użytkownika można sprawdzić, czy klient prawidłowo wyświetla komunikat, ale zasadnicza przyczyna znajduje się zwykle w logice usługi obsługującej kampanie, w transakcji zapisującej licznik albo w konfiguracji mechanizmu kolejkowania. Naprawa powinna obejmować test pojedynczego przekroczenia, serię równoczesnych żądań oraz próbę ponowienia połączenia, aby potwierdzić, że ograniczenie działa niezależnie od użytego interfejsu.