Wstęp
Wyobraź sobie aplikację, w której każde działanie użytkownika wyzwala natychmiastową reakcję systemu – bez opóźnień, bez zbędnych zapytań do bazy, bez przeciążania serwera. Brzmi jak marzenie? Dla wielu firm to codzienność dzięki Event-Driven Architecture (EDA). Jednak większość projektów wciąż opiera się na synchronicznych łańcuchach wywołań, które przy skali zaczynają dusić biznes.
W tym artykule przyjrzymy się trzem konkretnym błędom, które popełniają zespoły backendowe przy implementacji EDA, oraz pokażę, jak ich uniknąć. Nie będzie teorii oderwanej od rzeczywistości – same lekcje z ognia.
1. Brak właściwej obsługi niepowodzeń: zakładanie, że event zawsze dotrze
Problem
W architekturze synchronicznej błędy są oczywiste – jeśli serwis A nie odpowie, serwis B dostaje timeout i może podjąć akcję. W EDA zakładamy, że eventy są niezawodne, ale to złudne. Twoja kolejka może się zapchać, broker może paść, a event może zostać przetworzony dwukrotnie.
Przykład z życia
Jeden z naszych klientów, platforma SaaS do zarządzania subskrypcjami, wdrożył EDA do obsługi płatności. Gdy klient dokonał płatności, wysyłali event do serwisu aktywującego dostęp. Niestety, z powodu braku idempotentności eventu, kilkukrotne wysłanie tego samego zdarzenia (np. po restarcie kolejki) skutkowało wielokrotnym odnowieniem subskrypcji na kilka dni. Klienci dostawali dostęp za darmo, a firma traciła przychody.
Rozwiązanie
Każdy event powinien mieć niepowtarzalny identyfikator (np. UUID), a serwis konsumujący musi być idempotentny – czyli przetworzenie tego samego eventu dwa razy daje ten sam skutek. Dodatkowo warto implementować dead letter queue (DLQ) dla eventów, które nie mogą zostać przetworzone, a nie po prostu je ignorować.
Biznesowa konsekwencja
Brak obsługi błędów w EDA prowadzi do utraty pieniędzy (niewłaściwe naliczenia), złego UX (np. zduplikowane zamówienia) i utraty zaufania. Wdrożenie idempotentności i DLQ to inwestycja, która zwraca się przy pierwszym poważnym błędzie.
2. Zbyt silne powiązanie eventów z konkretnymi serwisami
Problem
Częsty błąd: tworzenie eventów, które są ściśle powiązane z implementacją konkretnych usług. Przykładowo, event orderPlaced niesie ze sobą cały obiekt zamówienia wraz z danymi klienta, produktami i cenami. Gdy zmienisz strukturę zamówienia, musisz zaktualizować wszystkich konsumentów. To zaprzecza idei luźnego sprzężenia.
Przykład z życia
Pracowałem kiedyś nad platformą e-commerce, gdzie zespół wysyłał w evencie pełen obiekt zamówienia. Gdy dodaliśmy pole discountCode, każdy konsument musiał zostać zaktualizowany, bo niektóre serwisy nie były przygotowane na nowe pole. Doszło do błędów deserializacji, a proces zamówień został zablokowany na kilka godzin.
Rozwiązanie
Eventy powinny być jak najbardziej ogólne i zawierać tylko niezbędne dane. Lepiej wysłać event order.placed z identyfikatorem zamówienia, a konsumenci niech sami pobiorą potrzebne szczegóły (np. przez API). Albo jeszcze lepiej: użyj eventów wzbogaconych o dane, które są stabilne i niezmienne w czasie (np. timestamp, typ zdarzenia).
Biznesowa konsekwencja
Zbytnia zależność od konkretnych danych w eventach spowalnia rozwój. Każda zmiana w modelu wymaga zmian w wielu serwisach. To zwiększa czas wprowadzania nowych funkcji i ryzyko błędów produkcyjnych. W dłuższej perspektywie firma traci przewagę konkurencyjną.
3. Pomijanie monitoringu i observability w EDA
Problem
W synchronicznej komunikacji łatwo śledzić przepływ – wystarczy logi i narzędzia APM. W EDA eventy płyną przez kolejki, a ich przetwarzanie jest asynchroniczne. Bez odpowiedniego monitoringu nie wiesz, czy event został przetworzony, utknął w kolejce, czy może przepadł.
Przykład z życia
Klient z branży logistycznej wdrożył EDA do śledzenia przesyłek. Po miesiącu okazało się, że część eventów dotyczących zmiany statusu – np. „przesyłka dostarczona” – była gubiona w przypadku przeciążenia systemu. Klienci nie dostawali powiadomień, a support był zalewany zapytaniami. Firma straciła reputację.
Rozwiązanie
Każdy event powinien być logowany na wejściu i wyjściu z systemu. Korzystaj z narzędzi do observability (np. OpenTelemetry), które pozwalają śledzić eventy przez cały łańcuch. Ustaw alerty na opóźnienia w kolejkach, liczby nieprzetworzonych eventów oraz błędy w DLQ.
Biznesowa konsekwencja
Brak widoczności w EDA prowadzi do cichych błędów, które kumulują się i wybuchają w najmniej oczekiwanym momencie. Klienci tracą zaufanie, a zespół spędza godziny na debugowaniu. Monitoring to nie opcja – to konieczność.
Podsumowanie
Event-Driven Architecture to potężne narzędzie, ale wymaga dojrzałości technicznej i przemyślanego projektowania. Unikając trzech opisanych błędów – braku idempotentności, zbytniego powiązania eventów z implementacją oraz pomijania monitoringu – możesz zbudować system, który skaluje się płynnie i jest odporny na awarie.
W JurskiTech wdrażamy EDA w projektach naszych klientów od lat. Wiemy, że diabeł tkwi w szczegółach. Jeśli planujesz migrację lub chcesz sprawdzić, czy Twój system nie popełnia tych błędów – skontaktuj się z nami. Pomożemy Ci uniknąć kosztownych pułapek.
