Event sourcing brzmi jak srebrna kula \u2013 zapisujesz wszystko, co si\u0119 wydarzy\u0142o, a potem odtwarzasz stan. W teorii \u015bwietnie: audytowalno\u015b\u0107, czasowa podr\u00f3\u017c, elastyczno\u015b\u0107. W praktyce? Widzia\u0142em startup, kt\u00f3ry po roku migracji do event sourcing mia\u0142 baz\u0119 zdarze\u0144 wi\u0119ksz\u0105 ni\u017c produkcyjny magazyn danych, a odtwarzanie stanu trwa\u0142o d\u0142u\u017cej ni\u017c pierwotne przetwarzanie. Dlaczego? Bo pope\u0142nili trzy klasyczne b\u0142\u0119dy.<\/p>\n
Ostrzegam: to nie jest kolejny poradnik \u201eevent sourcing dla pocz\u0105tkuj\u0105cych\u201d. To opowie\u015b\u0107 o tym, jak \u017ale zaprojektowany event sourcing mo\u017ce zabi\u0107 Tw\u00f3j SaaS \u2013 i jak tego unikn\u0105\u0107.<\/p>\n
Najcz\u0119stszy grzech. Zamiast modelowa\u0107 zdarzenia jako fakty biznesowe, programi\u015bci zapisuj\u0105 w eventach ca\u0142y stan obiektu. Przyk\u0142ad: w systemie zarz\u0105dzania zam\u00f3wieniami, zamiast eventu Lekcja:<\/strong> Ka\u017cdy event powinien opisywa\u0107 tylko to, co si\u0119 zmieni\u0142o. U\u017cywaj minimalnych, semantycznych zdarze\u0144. Pami\u0119taj: event sourcing to nie backup stanu, to dziennik fakt\u00f3w.<\/p>\n Kiedy startupy s\u0142ysz\u0105 \u201eodtwarzanie stanu z event\u00f3w\u201d, cz\u0119sto wyobra\u017caj\u0105 sobie idealn\u0105 lini\u0119 czasu \u2013 replay od pocz\u0105tku. W praktyce, dla agregat\u00f3w z d\u0142ug\u0105 histori\u0105 (np. koszyk zakupowy u\u017cytkownika z 3 latami aktywno\u015bci) replay setek event\u00f3w za ka\u017cdym \u017c\u0105daniem to proszenie si\u0119 o problemy wydajno\u015bciowe. Widzia\u0142em system, w kt\u00f3rym odtworzenie profilu klienta wymaga\u0142o przetworzenia 12 000 event\u00f3w. Czas odpowiedzi: 8 sekund. U\u017cytkownicy klikali F5 jak szaleni. <\/p>\n Rozwi\u0105zanie? Snapshoting. Regularnie zapisuj stan agregatu, a eventy replayuj tylko od ostatniego snapshota. W cytowanym przypadku zmiana skr\u00f3ci\u0142a czas odpowiedzi do 200 ms. Ale uwaga \u2013 zbyt cz\u0119ste snapshoty zabijaj\u0105 korzy\u015bci z event sourcingu (audyt, elastyczno\u015b\u0107). Znajd\u017a z\u0142oty \u015brodek: snapshootuj co 100 event\u00f3w lub co 24 godziny.<\/p>\n Event sourcing daje poczucie bezpiecze\u0144stwa \u2013 wszystko jest zapisane, wi\u0119c mo\u017cna odtworzy\u0107. Problem w tym, \u017ce event store to z\u0142o\u017cona infrastruktura (cz\u0119sto oparta na bazie NoSQL lub dedykowanym narz\u0119dziu). Awarie si\u0119 zdarzaj\u0105. Widzia\u0142em firm\u0119, kt\u00f3ra straci\u0142a godzin\u0119 danych, bo klastra EventStoreDB nagle odm\u00f3wi\u0142 pos\u0142usze\u0144stwa, a replikacja nie dzia\u0142a\u0142a poprawnie. Bez tradycyjnych backup\u00f3w odtworzenie stanu by\u0142o niemo\u017cliwe \u2013 niekt\u00f3re eventy nie zosta\u0142y zflushowane. Kosztowa\u0142o to startup 3 dni przestoju i utrat\u0119 zaufania klient\u00f3w.<\/p>\n Lekcja:<\/strong> Event store musi by\u0107 regularnie backupowany do chmury (np. S3) z testami przywracania. Dodatkowo, rozwa\u017c r\u00f3wnoleg\u0142e przechowywanie aktualnego stanu w klasycznej bazie (CQRS) \u2013 wtedy nawet je\u015bli event store padnie, masz punkt startowy do replayu od ostatniego snapshota.<\/p>\n Event sourcing to pot\u0119\u017cne narz\u0119dzie, ale nie jest srebrn\u0105 kul\u0105. Klucz to \u015bwiadome projektowanie: lekkie eventy, snapshoty, backup. Bez tego Tw\u00f3j SaaS mo\u017ce sta\u0107 si\u0119 ofiar\u0105 w\u0142asnej architektury. Zanim wdro\u017cysz event sourcing, zadaj sobie pytanie: czy faktycznie potrzebujesz pe\u0142nej audytowalno\u015bci i czasowej podr\u00f3\u017cy? Dla wielu system\u00f3w wystarczy klasyczna baza + logi zmian. Ale je\u015bli decydujesz si\u0119 na event sourcing \u2013 unikaj trzech opisanych b\u0142\u0119d\u00f3w. Twoi u\u017cytkownicy (i bud\u017cet) ci podzi\u0119kuj\u0105.<\/p>\n Potrzebujesz pomocy w ocenie architektury swojego SaaS? W JurskiTech sprawdzamy wydajno\u015b\u0107 i skalowalno\u015b\u0107 backendu \u2013 cz\u0119sto wystarczy kilka poprawek, by system oddycha\u0142 pe\u0142n\u0105 piersi\u0105.<\/p>\n","protected":false},"excerpt":{"rendered":" Dlaczego Tw\u00f3j SaaS umiera przez z\u0142e event sourcing? 3 lekcje z backendu Event sourcing brzmi jak srebrna kula \u2013 zapisujesz wszystko, co si\u0119 wydarzy\u0142o, a potem odtwarzasz stan. W teorii \u015bwietnie: audytowalno\u015b\u0107, czasowa podr\u00f3\u017c, elastyczno\u015b\u0107. W praktyce? Widzia\u0142em startup, kt\u00f3ry po roku migracji do event sourcing mia\u0142 baz\u0119 zdarze\u0144 wi\u0119ksz\u0105 ni\u017c produkcyjny magazyn danych, a<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[276,556,513,514,94],"class_list":["post-1843","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-architektura-api","tag-architektura-backend","tag-bledy-ai","tag-event-sourcing","tag-saas"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1843","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=1843"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1843\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=1843"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=1843"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=1843"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}OrderPlaced{orderId, customerId, total}<\/code> dostajesz OrderUpdated{zOrder, zLineItems, zAddress...}<\/code> \u2013 kopi\u0119 ca\u0142ego 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\u00f3w. Testowa\u0142em takie rozwi\u0105zanie u klienta: przy 5 milionach event\u00f3w odtwarzanie stanu jednego zam\u00f3wienia trwa\u0142o \u015brednio 4 sekundy. Po zmianie na lekkie eventy \u2013 200 milisekund. <\/p>\nB\u0142\u0105d 2: Brak snapshot\u00f3w \u2013 i utopia czystej architektury<\/h3>\n
B\u0142\u0105d 3: Event store jako jedyne \u017ar\u00f3d\u0142o prawdy bez backupu<\/h3>\n
Podsumowanie<\/h3>\n