Wprowadzenie
Znasz to uczucie, gdy aplikacja działa poprawnie, ale każda większa zmiana wiąże się z tygodniami debugowania? Albo gdy klient pyta o historię zmian konkretnego zamówienia, a Ty nie masz bladego pojęcia, jak to odtworzyć? Widzę to u coraz większej liczby firm – wybierają na początku prostą architekturę CRUD, bo „szybciej”, a potem płacą dług techniczny.
Event Sourcing to nie modny buzzword. To odpowiedź na konkretne problemy biznesowe: audyt, skalowanie, spójność danych w rozproszonym systemie. Ale czy każda aplikacja go potrzebuje? Dziś pokażę trzy scenariusze, w których wdrożenie Event Sourcingu realnie zmieniło los projektu.
1. Audyt i śledzenie zmian w systemie finansowym
Wyobraź sobie system do zarządzania subskrypcjami SaaS. Każda zmiana planu, anulowanie, przedłużenie – to zdarzenia, które muszą być rejestrowane. W typowym CRUD zapisujesz tylko ostatni stan. Jeśli klient twierdzi, że został błędnie naliczony rachunek, musisz przekopywać logi, które często są niekompletne.
Jak wygląda to w praktyce?
Pracowałem z firmą oferującą platformę do fakturowania. Ich klasyczna baza danych pozwalała na łatwe wyciągnięcie aktualnego statusu faktury, ale nie historię zmian. Gdy klient zgłaszał reklamację, programista musiał ręcznie analizować tabele audytowe, które notowały tylko różnice. Zajmowało to godziny, a często kończyło się na „nie wiemy, co się stało”.
Po migracji na Event Sourcing każda zmiana statusu faktury (utworzona, wysłana, opłacona, anulowana) to osobne zdarzenie. Możesz odtworzyć stan faktury w dowolnym momencie. Co więcej, zdarzenia są niemutowalne – nie można ich usunąć ani zmienić. To daje komfort prawny i ułatwia audyt.
Kiedy to wdrożyć?
Jeśli twoja aplikacja operuje na danych, które mają znaczenie prawne (finanse, dokumenty, rejestracje), Event Sourcing to nie opcja, a konieczność. Koszt implementacji jest wyższy, ale oszczędzasz na wsparciu technicznym i unikasz ryzyka sporów.
2. Skalowanie mikroserwisów i spójność danych w e-commerce
W e-commerce każda akcja użytkownika to potencjalne zdarzenie: dodanie do koszyka, zmiana adresu, złożenie zamówienia, płatność. W klasycznej architekturze, jeśli jeden mikroserwis padnie, możesz stracić dane lub naruszyć spójność – zamówienie zostanie zapisane w serwisie A, ale nie w serwisie B.
Konkretny przypadek
Klient prowadził sklep z odzieżą. Stosował klasyczną bazę relacyjną dla zamówień, a magazynowy API działał osobno. Gdy po złożeniu zamówienia system magazynowy przestawał działać, zamówienie traciło stan – klient widział „w realizacji”, a tak naprawdę towar nie był rezerwowany. Po kilku godzinach ręcznego doładania danych, w końcu wdrożyli Event Sourcing na kluczowych agregatach: zamówienie i koszyk.
Każda zmiana zamówienia (np. dodanie produktu) to zdarzenie rozsyłane do odbiorców (magazyn, płatność, powiadomienia). Dzięki temu, gdy któryś serwis jest niedostępny, zdarzenia czekają w kolejce i zostaną przetworzone później. Zamówienie zawsze ma pełną historię, a spójność ostateczna jest lepsza niż hazard z transakcjami rozproszonymi.
Rekomendacja
Event Sourcing nie jest konieczny w małych e-commerce, ale w przypadku większej skali (powyżej 50 tys. zamówień miesięcznie) i wielu integracji (płatności, wysyłki) znacznie redukuje ryzyko utraty danych i błędów.
3. Odtwarzanie stanu w systemach IoT i konfiguracjach urządzeń
Wyobraź sobie platformę zarządzającą flotą czujników IoT. Każdy czujnik wysyła dane, zmienia konfigurację, przechodzi w tryb offline. Standardowa baza danych notuje ostatni stan, ale nie historię przejść. Gdy urządzenie się resetuje, tracisz kontekst, dlaczego znalazło się w danym stanie.
Przykład z życia
Pracowałem z startupem oferującym inteligentne zamki do drzwi w biurach. Chcieli logować każdą akcję: otwarcie, zamknięcie, zmiana kodu PIN, wyłączenie. CRUD pozwalał tylko na odczyt aktualnego stanu, a debugowanie problemów wymagało przeszukiwania logów aplikacji. Po przejściu na Event Sourcing mogli odtworzyć sekwencję zdarzeń dla każdego zamka. Gdy zamek nie zareagował na polecenie, analizowali strumień zdarzeń i znajdowali przyczynę (np. brak potwierdzenia z sieci).
Wnioski
Event Sourcing w IoT daje przewagę, gdy wymagana jest pełna historia lub weryfikacja poprawności działania. Koszt wdrożenia jest wyższy, ale oszczędza czas na diagnostyce i zwiększa niezawodność.
Kiedy nie stosować Event Sourcingu?
To nie jest srebrna kula. Jeśli twoje dane są ulotne (np. sesje użytkowników, cache), a nie potrzebujesz historii – nie warto. Event Sourcing zwiększa złożoność: potrzebujesz event store, obsługi zdarzeń niemutowalnych, narzędzi do odtwarzania. Dla prostych aplikacji biurowych to przerost formy nad treścią.
Podsumowanie
Event Sourcing rozwiązuje realne problemy: audytowalność, skalowanie w mikroserwisach, odtwarzanie stanu w systemach zdarzeniowych. Wdrożyłem go w kilkunastu projektach i za każdym razem przynosił korzyści, gdy biznes wymagał pełnej kontroli nad historią danych. Jeśli rozważasz tę architekturę, zacznij od małych agregatów – np. zamówienia lub faktury – i zobacz, jak zmienia się komfort pracy twórców i dynamika systemu. Twoja aplikacja nie przegra z konkurencją przez brak Event Sourcingu, ale może przegrać, jeśli nie zareagujesz na sygnały, które go wymagają.
A Ty? Zmagasz się z problemami audytu lub spójności w swoim systemie? Zastanów się, czy właśnie nie nadszedł czas na Event Sourcing.
