Architektura zdarzeniowa (event-driven) brzmi kusząco – obiecuje elastyczność, skalowalność i luźne powiązania między serwisami. W e-commerce, gdzie każda sekunda przestoju kosztuje sprzedaż, wydaje się być świętym Graalem. Ale diabeł tkwi w szczegółach.
Widzę to w projektach, do których wchodzę jako konsultant: zespoły skaczą na event-driven z entuzjazmem, a po pół roku mają piekło na ziemi. Przeanalizuję trzy konkretne błędy, które regularnie powtarzają małe i średnie firmy. Bez teorii, tylko praktyka.
1. Chaos w definiowaniu zdarzeń
Zaczyna się niewinnie. Ktoś rzuca: „Robimy event-driven, więc każda zmiana stanu to zdarzenie”. I nagle masz zdarzenia orderCreated, orderUpdated, orderConfirmed, orderPacked, orderShipped, orderDelivered, a do tego paymentReceived, paymentFailed, paymentRefunded… lista rośnie.
Problem? Po trzech miesiącach nikt nie wie, które zdarzenia są krytyczne, a które to tylko szum. Zaczynasz łapać wszystko, żeby niczego nie przegapić. W efekcie masz szambo, nie system.
Przykład z życia: Klient – sklep z butami, 50 tys. zamówień miesięcznie. Zespół zdefiniował 120 typów zdarzeń. System działał wolno, bo każdy serwis subskrybował tony niepotrzebnych komunikatów. Po audycie zostawili 12 zdarzeń biznesowych. Wydajność wzrosła 4-krotnie.
Jak to naprawić? Zdarzenia powinny odzwierciedlać fakty biznesowe, nie techniczne. Każde zdarzenie to coś, co ma znaczenie dla domeny – orderPlaced, paymentSettled, stockExhausted. Reszta to implementacja, która nie musi być rozgłaszana.
2. Zapomnienie o idempotentności
W architekturze zdarzeniowej gwarancja dostarczenia komunikatu „dokładnie raz” jest iluzją. W praktyce dostajesz „co najmniej raz”. Brak idempotentności to prosta droga do katastrofy.
Wyobraź sobie: klient składa zamówienie, system wystawia event orderPlaced. Broker (np. Kafka czy RabbitMQ) z przyczyn sieciowych wyśle go dwa razy. Jeśli Twoja usługa płatności nie sprawdzi duplikatu, obciąży kartę podwójnie. Klient wpada w furię, chargeback, zła opinia.
Przykład z życia: Firma sprzedająca bilety. Podczas promocji czarna pizza – system zduplikował zamówienia. Sprzedali dwa razy więcej biletów niż mieli. Chaos, zwroty, kryzys komunikacyjny.
Jak to naprawić? Każda usługa przetwarzająca zdarzenie musi być idempotentna. Najprostszy sposób: nadaj zdarzeniom unikalne ID i przechowuj je po stronie odbiorcy w bazie (np. z indeksem unique). Przed przetworzeniem sprawdzasz, czy już to widziałeś. Koszt mały, zysk ogromny.
3. Brak strategii debugowania i monitorowania
Przy architekturze synchronicznej (REST) wiesz, który serwis padł i gdzie szukać logów. Przy event-driven jest jak w czarnej skrzynce – zdarzenie płynie przez kilka serwisów, każdy coś robi, a jeśli coś pójdzie źle, nie wiadomo, gdzie szukać.
Zespoły często nie myślą o tym na początku. Dopiero gdy pojawia się bug, spędzają dni na szukaniu, który serwis zgubił event. A klienci czekają na zamówienia.
Przykład z życia: E-commerce z modą. Wdrożyli event-driven dla aktualizacji stanów magazynowych. Po dwóch tygodniach zaczęły się problemy – klienci kupowali rzeczy, które były w koszyku innych. Debugowanie trwało tydzień. Okazało się, że jeden serwis nie przetwarzał zdarzeń w kolejności, powodując race condition. Bez odpowiedniego śledzenia (distributed tracing) znalezienie tego zajęło wieczność.
Jak to naprawić? Od dnia 1 używaj narzędzi do distributed tracing (np. Jaeger, Zipkin). Każde zdarzenie powinno nieść ze sobą unikalny identyfikator korelacji (correlation ID). Dodaj też logowanie strukturalne i metryki (np. opóźnienia przetwarzania, liczba zdarzeń w kolejce). To nie jest opcja – to konieczność.
Podsumowanie
Architektura zdarzeniowa w e-commerce ma sens – szczególnie gdy masz wiele serwisów komunikujących się asynchronicznie. Ale bez zdyscyplinowania w definiowaniu zdarzeń, dbałości o idempotentność i solidnego monitoringu, zamienia się w koszmar.
Zanim rzucisz się w wir implementacji, zadaj sobie trzy pytania: Czy moje zdarzenia są naprawdę biznesowe? Czy każdy odbiorca jest idempotentny? Czy mam narzędzia do debugowania złożonych przepływów? Jeśli choć na jedno odpowiedź brzmi „nie” – zatrzymaj się. Lepiej spowolnić teraz, niż gasić pożary później.
JurskiTech specjalizuje się w projektowaniu architektury zdarzeniowej odpornej na błędy. Jeśli potrzebujesz audytu lub wsparcia wdrożeniowego – daj znać.
