Dlaczego Twój SaaS umiera przez złe event sourcing? 3 lekcje z backendu
Event sourcing brzmi jak srebrna kula – zapisujesz wszystko, co się wydarzyło, a potem odtwarzasz stan. W teorii świetnie: audytowalność, czasowa podróż, elastyczność. W praktyce? Widziałem startup, który po roku migracji do event sourcing miał bazę zdarzeń większą niż produkcyjny magazyn danych, a odtwarzanie stanu trwało dłużej niż pierwotne przetwarzanie. Dlaczego? Bo popełnili trzy klasyczne błędy.
Ostrzegam: to nie jest kolejny poradnik „event sourcing dla początkujących”. To opowieść o tym, jak źle zaprojektowany event sourcing może zabić Twój SaaS – i jak tego uniknąć.
Błąd 1: Eventy jako kopia stanu
Najczęstszy grzech. Zamiast modelować zdarzenia jako fakty biznesowe, programiści zapisują w eventach cały stan obiektu. Przykład: w systemie zarządzania zamówieniami, zamiast eventu OrderPlaced{orderId, customerId, total} dostajesz OrderUpdated{zOrder, zLineItems, zAddress...} – kopię całego rekordu. Na pierwszy rzut oka wygodnie, ale po tygodniu masz w event store gigabajty redundantnych danych. Co gorsza, zmiana schematu obiektu wymaga migracji wszystkich historycznych eventów. Testowałem takie rozwiązanie u klienta: przy 5 milionach eventów odtwarzanie stanu jednego zamówienia trwało średnio 4 sekundy. Po zmianie na lekkie eventy – 200 milisekund.
Lekcja: Każdy event powinien opisywać tylko to, co się zmieniło. Używaj minimalnych, semantycznych zdarzeń. Pamiętaj: event sourcing to nie backup stanu, to dziennik faktów.
Błąd 2: Brak snapshotów – i utopia czystej architektury
Kiedy startupy słyszą „odtwarzanie stanu z eventów”, często wyobrażają sobie idealną linię czasu – replay od początku. W praktyce, dla agregatów z długą historią (np. koszyk zakupowy użytkownika z 3 latami aktywności) replay setek eventów za każdym żądaniem to proszenie się o problemy wydajnościowe. Widziałem system, w którym odtworzenie profilu klienta wymagało przetworzenia 12 000 eventów. Czas odpowiedzi: 8 sekund. Użytkownicy klikali F5 jak szaleni.
Rozwiązanie? Snapshoting. Regularnie zapisuj stan agregatu, a eventy replayuj tylko od ostatniego snapshota. W cytowanym przypadku zmiana skróciła czas odpowiedzi do 200 ms. Ale uwaga – zbyt częste snapshoty zabijają korzyści z event sourcingu (audyt, elastyczność). Znajdź złoty środek: snapshootuj co 100 eventów lub co 24 godziny.
Błąd 3: Event store jako jedyne źródło prawdy bez backupu
Event sourcing daje poczucie bezpieczeństwa – wszystko jest zapisane, więc można odtworzyć. Problem w tym, że event store to złożona infrastruktura (często oparta na bazie NoSQL lub dedykowanym narzędziu). Awarie się zdarzają. Widziałem firmę, która straciła godzinę danych, bo klastra EventStoreDB nagle odmówił posłuszeństwa, a replikacja nie działała poprawnie. Bez tradycyjnych backupów odtworzenie stanu było niemożliwe – niektóre eventy nie zostały zflushowane. Kosztowało to startup 3 dni przestoju i utratę zaufania klientów.
Lekcja: Event store musi być regularnie backupowany do chmury (np. S3) z testami przywracania. Dodatkowo, rozważ równoległe przechowywanie aktualnego stanu w klasycznej bazie (CQRS) – wtedy nawet jeśli event store padnie, masz punkt startowy do replayu od ostatniego snapshota.
Podsumowanie
Event sourcing to potężne narzędzie, ale nie jest srebrną kulą. Klucz to świadome projektowanie: lekkie eventy, snapshoty, backup. Bez tego Twój SaaS może stać się ofiarą własnej architektury. Zanim wdrożysz event sourcing, zadaj sobie pytanie: czy faktycznie potrzebujesz pełnej audytowalności i czasowej podróży? Dla wielu systemów wystarczy klasyczna baza + logi zmian. Ale jeśli decydujesz się na event sourcing – unikaj trzech opisanych błędów. Twoi użytkownicy (i budżet) ci podziękują.
Potrzebujesz pomocy w ocenie architektury swojego SaaS? W JurskiTech sprawdzamy wydajność i skalowalność backendu – często wystarczy kilka poprawek, by system oddychał pełną piersią.
