Zdarzeniowo\u015b\u0107 brzmi jak panaceum na skalowanie. W teorii \u2013 system reaguj\u0105cy na zdarzenia, asynchroniczny, elastyczny. W praktyce \u2013 widz\u0119 startup za startupem, kt\u00f3re wpadaj\u0105 w pu\u0142apk\u0119 \u201eevent-driven everything\u201d i ko\u0144cz\u0105 z architektur\u0105, kt\u00f3ra dzia\u0142a tylko w prezentacjach na konferencjach.<\/p>\n
Pracowa\u0142em przy migracji kilku system\u00f3w SaaS do architektury zdarzeniowej. Niekt\u00f3re odnios\u0142y sukces. Inne \u2013 po roku przepisa\u0142y wszystko od nowa. Oto trzy b\u0142\u0119dy, kt\u00f3re widz\u0119 najcz\u0119\u015bciej.<\/p>\n
Pierwszy b\u0142\u0105d to traktowanie zdarze\u0144 jak uniwersalnego kleju. Zespo\u0142y wrzucaj\u0105 wszystko do kolejki: logowanie u\u017cytkownika, zmian\u0119 statusu zam\u00f3wienia, klikni\u0119cie w przycisk, a nawet ping serwisu monitoruj\u0105cego. Efekt? System staje si\u0119 czarn\u0105 skrzynk\u0105, w kt\u00f3rej nikt nie panuje nad przep\u0142ywem.<\/p>\n
Przyk\u0142ad z \u017cycia:<\/strong> Klient \u2013 platforma SaaS do zarz\u0105dzania projektami. Wdro\u017cyli event sourcing, ale ka\u017cda akcja u\u017cytkownika generowa\u0142a zdarzenie. W szczycie \u2013 50 000 zdarze\u0144 na sekund\u0119. Broker (RabbitMQ) nie dawa\u0142 rady, konsumenci si\u0119 dusili. Rozwi\u0105zanie? Filtrowanie zdarze\u0144 na wej\u015bciu \u2013 tylko te istotne dla logiki biznesowej przechodzi\u0142y dalej.<\/p>\n Konsekwencje dla biznesu:<\/strong> Op\u00f3\u017anienia w przetwarzaniu zam\u00f3wie\u0144, frustracja u\u017cytkownik\u00f3w, utrata sprzeda\u017cy.<\/p>\n Zasada:<\/strong> Nie ka\u017cde klikni\u0119cie musi by\u0107 zdarzeniem. Zdarzenia to komunikaty o faktach, kt\u00f3re maj\u0105 znaczenie dla innych us\u0142ug. Je\u015bli nikt nie s\u0142ucha \u2013 nie wysy\u0142aj.<\/p>\n Drugi b\u0142\u0105d to za\u0142o\u017cenie, \u017ce wystarczy wys\u0142a\u0107 zdarzenie, a ono dotrze. W systemie rozproszonym zdarzenia mog\u0105 gin\u0105\u0107, duplikowa\u0107 si\u0119, zmienia\u0107 kolejno\u015b\u0107. Zespo\u0142y cz\u0119sto pomijaj\u0105 mechanizmy potwierdzenia (ack), retransmisji lub deduplikacji.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Firma e-commerce u\u017cywa\u0142a Kafka do obs\u0142ugi zam\u00f3wie\u0144. Po awarii sieci cz\u0119\u015b\u0107 zdarze\u0144 zagin\u0119\u0142a. Klienci nie otrzymali potwierdze\u0144, zam\u00f3wienia znikn\u0119\u0142y. Przyczyna? Brak idempotentno\u015bci konsument\u00f3w \u2013 po ponownym dostarczeniu zdarzenia system tworzy\u0142 duplikaty zam\u00f3wie\u0144.<\/p>\n Rozwi\u0105zanie:<\/strong> Idempotentne konsumenci, unikalne ID zdarzenia, a w razie potrzeby \u2013 transakcyjne outbox (np. tabela w bazie danych, z kt\u00f3rej dedykowany proces odczytuje i wysy\u0142a zdarzenia).<\/p>\n Konsekwencje:<\/strong> Utrata zaufania, koszty zwrot\u00f3w, r\u0119czna interwencja dzia\u0142u IT.<\/p>\n Event sourcing \u2013 czyli przechowywanie tylko strumienia zdarze\u0144, z kt\u00f3rego odtwarza si\u0119 stan. Brzmi elegancko, ale w praktyce bywa koszmarem. Zdarzenia s\u0105 niezmienne, ale schematy danych ewoluuj\u0105. Bez strategii migracji \u2013 po roku masz 100 r\u00f3\u017cnych wersji zdarze\u0144, a odtworzenie stanu trwa godziny.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Startup fintech \u2013 event sourcing jako g\u0142\u00f3wna warstwa danych. Po zmianie regulacji musieli doda\u0107 nowe pole do zdarzenia. Brak backward compatibility \u2013 stare zdarzenia przesta\u0142y pasowa\u0107. Kod do migracji r\u00f3s\u0142, a performance spada\u0142. Ostatecznie wprowadzili snapshoty (stan okresowo zapisywany), co skr\u00f3ci\u0142o czas odtwarzania z 2 godzin do 5 minut.<\/p>\n Konsekwencje:<\/strong> Wolne raporty, problemy z audytem, blokada developmentu.<\/p>\n Zasada:<\/strong> Event sourcing ma sens, gdy potrzebujesz pe\u0142nego audytu lub analizy historycznej. Dla zwyk\u0142ego CRUD-u \u2013 lepiej zosta\u0107 przy tradycyjnym modelu z opcjonalnym logiem zdarze\u0144.<\/p>\n Architektura zdarzeniowa to pot\u0119\u017cne narz\u0119dzie, ale wymaga dyscypliny. Zanim wrzucisz eventy do swojego SaaS, odpowiedz sobie na trzy pytania:<\/p>\n Je\u015bli odpowied\u017a na kt\u00f3re\u015b brzmi \u201enie\u201d \u2013 lepiej wr\u00f3ci\u0107 do prostszej architektury. Albo zaprosi\u0107 kogo\u015b z do\u015bwiadczeniem, kto pomo\u017ce unikn\u0105\u0107 tych b\u0142\u0119d\u00f3w.<\/p>\n W JurskiTech.pl cz\u0119sto widzimy firmy, kt\u00f3re przep\u0142acaj\u0105 za \u201emodne\u201d rozwi\u0105zania, podczas gdy potrzebuj\u0105 solidnego fundamentu. Architektura zdarzeniowa \u2013 tak, ale z g\u0142ow\u0105.<\/p>\n","protected":false},"excerpt":{"rendered":" Wst\u0119p Zdarzeniowo\u015b\u0107 brzmi jak panaceum na skalowanie. W teorii \u2013 system reaguj\u0105cy na zdarzenia, asynchroniczny, elastyczny. W praktyce \u2013 widz\u0119 startup za startupem, kt\u00f3re wpadaj\u0105 w pu\u0142apk\u0119 \u201eevent-driven everything\u201d i ko\u0144cz\u0105 z architektur\u0105, kt\u00f3ra dzia\u0142a tylko w prezentacjach na konferencjach. Pracowa\u0142em przy migracji kilku system\u00f3w SaaS do architektury zdarzeniowej. Niekt\u00f3re odnios\u0142y sukces. Inne \u2013 po<\/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":[476,116,94,24],"class_list":["post-1784","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-architektura-zdarzeniowa","tag-bledy-it","tag-saas","tag-skalowalnosc"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1784","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=1784"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1784\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=1784"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=1784"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=1784"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}2. Brak gwarancji dostarczenia \u2013 czyli \u201eeventy gubi\u0105 si\u0119 w drodze\u201d<\/h2>\n
3. Zdarzenia jako jedyne \u017ar\u00f3d\u0142o prawdy \u2013 pu\u0142apka event sourcingu<\/h2>\n
Podsumowanie<\/h2>\n
\n