Event-driven architecture (EDA)<\/strong> brzmi jak odpowied\u017a na wszystkie problemy skalowalno\u015bci. W teorii \u2013 asynchroniczno\u015b\u0107, lu\u017ane powi\u0105zania, \u0142atwe dodawanie nowych funkcji. W praktyce \u2013 widzia\u0142em ju\u017c kilka system\u00f3w, kt\u00f3re po wdro\u017ceniu EDA generowa\u0142y wi\u0119cej problem\u00f3w ni\u017c rozwi\u0105zywa\u0142y. Cz\u0119sto s\u0142ysz\u0119 od CTO: \u201eprzeszli\u015bmy na eventy, ale aplikacja sta\u0142a si\u0119 wolniejsza, a debugowanie \u2013 koszmarem\u201d. Dlaczego? Bo architektura event\u00f3w nie polega tylko na wrzuceniu kolejki i nadawaniu nazw. To decyzje o sp\u00f3jno\u015bci, kolejno\u015bci, obs\u0142udze b\u0142\u0119d\u00f3w i idempotentno\u015bci. W tym artykule pokazuj\u0119 trzy realne b\u0142\u0119dy, kt\u00f3re widzia\u0142em w SaaS-ach \u015bredniej wielko\u015bci \u2013 i jak je rozwi\u0105za\u0107.<\/p>\n Wyobra\u017a sobie system zam\u00f3wie\u0144 w e-commerce. Klient sk\u0142ada zam\u00f3wienie, potem anuluje, a po chwili zmienia adres dostawy. Kolejno\u015b\u0107 ma znaczenie: najpierw tworzymy zam\u00f3wienie, potem anulujemy, potem aktualizujemy \u2013 ale aktualizacja powinna zosta\u0107 odrzucona, bo zam\u00f3wienie jest anulowane. Je\u015bli eventy trafi\u0105 do kolejki w innej kolejno\u015bci (np. z powodu op\u00f3\u017anienia sieciowego lub restarta konsumenta), mo\u017cesz sko\u0144czy\u0107 z zam\u00f3wieniem \u201ezaakceptowanym\u201d po anulacji.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Klient \u2013 SaaS do zarz\u0105dzania subskrypcjami. Mieli problem: u\u017cytkownicy otrzymywali maile z potwierdzeniem zmiany planu, kt\u00f3re by\u0142y wysy\u0142ane przed faktyczn\u0105 zmian\u0105 w systemie. Pow\u00f3d? Eventy wysy\u0142ane asynchronicznie, ale konsument przetwarza\u0142 je r\u00f3wnolegle, a kolejno\u015b\u0107 gwarantowana by\u0142a tylko w ramach jednej partycji \u2013 kt\u00f3rej nie ustawili. Rozwi\u0105zanie? Wprowadzenie sequence number<\/strong> lub u\u017cycie event sourcingu<\/strong> z agregacj\u0105 stanu. Pro\u015bciej: wyb\u00f3r brokera z gwarancj\u0105 kolejno\u015bci (np. Kafka z kluczem partycji) albo zastosowanie outbox pattern<\/strong> z zachowaniem kolejno\u015bci w bazie danych.<\/p>\n Lekcja:<\/strong> Je\u015bli kolejno\u015b\u0107 event\u00f3w ma znaczenie (a prawie zawsze ma dla sp\u00f3jno\u015bci danych), nie zak\u0142adaj, \u017ce kolejka jest domy\u015blnie FIFO. Zaprojektuj mechanizm weryfikacji \u2013 wersjonowanie event\u00f3w, timestampy, a najlepiej \u2013 u\u017cywaj zdarze\u0144, kt\u00f3re nios\u0105 pe\u0142ny stan, a nie tylko r\u00f3\u017cnic\u0119.<\/p>\n Ka\u017cdy system dystrybucyjny ma op\u00f3\u017anienia, timeouty, retransmisje. Je\u015bli konsument eventu nie jest idempotentny, pojedyncze zdarzenie mo\u017ce by\u0107 przetworzone wielokrotnie. W SaaS oznacza to: naliczenie op\u0142aty dwa razy, wys\u0142anie dw\u00f3ch maili, utworzenie dw\u00f3ch rekord\u00f3w.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Startup fintechowy \u2013 system rozlicze\u0144 dla subskrypcji. Broker wysy\u0142a\u0142 event \u201epayment.success\u201d, ale przy problemach sieciowych \u2013 zdarza\u0142y si\u0119 duplikaty. System tworzy\u0142 nowy rekord p\u0142atno\u015bci za ka\u017cdym razem. Klient widzia\u0142 podw\u00f3jne obci\u0105\u017cenie na karcie, a support ton\u0105\u0142 w reklamacjach. Rozwi\u0105zanie? Ka\u017cdy event musi mie\u0107 unikalny identyfikator (np. UUID), a konsument sprawdza\u0107, czy ju\u017c przetworzy\u0142 event o danym ID. Mo\u017cna to zrobi\u0107 w bazie danych (UNIQUE constraint) lub w pami\u0119ci (np. Redis TTL).<\/p>\n Lekcja:<\/strong> Zawsze zak\u0142adaj, \u017ce event mo\u017ce by\u0107 dostarczony wi\u0119cej ni\u017c raz. Wprowad\u017a idempotentno\u015b\u0107 na poziomie konsumenta. U\u017cywaj deduplikacji po stronie odbiorcy, a nie brokera.<\/p>\n Cz\u0119sty dylemat: jak du\u017cy powinien by\u0107 event? Jedni tworz\u0105 mikro-eventy (\u201ekolorZmieniony\u201d, \u201eadresZaktualizowany\u201d) \u2013 to zalewa system setkami zdarze\u0144. Inni wysy\u0142aj\u0105 jeden wielki \u201eobiektZmieniony\u201d z ca\u0142ym stanem \u2013 to zmusza konsument\u00f3w do parsowania i przetwarzania niepotrzebnych danych, a tak\u017ce zwi\u0119ksza rozmiar wiadomo\u015bci i op\u00f3\u017anienia.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Platforma SaaS do zarz\u0105dzania projektami. Zdefiniowali event \u201etaskUpdated\u201d zawieraj\u0105cy tylko ID zadania. Ka\u017cdy konsument musia\u0142 robi\u0107 osobne zapytanie do API, aby pobra\u0107 pe\u0142ne dane. Skutek: lawina zapyta\u0144, op\u00f3\u017anienia, wysoki koszt operacji. Po zmianie na eventy zawieraj\u0105ce pe\u0142ny stan (np. \u201etaskUpdated\u201d z polem \u201estatus\u201d, \u201eassignee\u201d, \u201edueDate\u201d) \u2013 konsumenci przetwarzali dane lokalnie, bez dodatkowych zapyta\u0144. Z drugiej strony, inny klient zrobi\u0142 jeden event \u201euserChanged\u201d dla ka\u017cdej zmiany u\u017cytkownika \u2013 konsumenci otrzymywali ca\u0142y obiekt, ale tylko 10% danych by\u0142o faktycznie u\u017cywane, wi\u0119c marnowali przepustowo\u015b\u0107.<\/p>\n Lekcja:<\/strong> Znajd\u017a z\u0142oty \u015brodek. U\u017cywaj selector event\u00f3w<\/strong> \u2013 ka\u017cdy event niech zawiera tylko pola istotne dla konsument\u00f3w. Je\u015bli masz r\u00f3\u017cne konsumenty potrzebuj\u0105ce r\u00f3\u017cnych danych, rozwa\u017c wysy\u0142anie kilku typ\u00f3w event\u00f3w (np. \u201etaskStatusChanged\u201d dla powiadomie\u0144, \u201etaskUpdated\u201d dla synchronizacji). Unikaj jednak przesadnej granularno\u015bci \u2013 zbyt wiele typ\u00f3w event\u00f3w zwi\u0119ksza z\u0142o\u017cono\u015b\u0107 zarz\u0105dzania.<\/p>\n Architektura eventowa to pot\u0119\u017cne narz\u0119dzie, ale wymaga \u015bwiadomych decyzji. Kolejno\u015b\u0107, idempotentno\u015b\u0107 i odpowiednia granularno\u015b\u0107 to trzy filary, kt\u00f3re decyduj\u0105 o tym, czy EDA przyniesie korzy\u015bci, czy stanie si\u0119 \u017ar\u00f3d\u0142em koszt\u00f3w. Zanim wdro\u017cysz kolejki i tematy, zastan\u00f3w si\u0119 nad konsekwencjami dla sp\u00f3jno\u015bci danych i \u0142atwo\u015bci debugowania.<\/p>\n Je\u015bli Tw\u00f3j SaaS boryka si\u0119 z problemami skalowalno\u015bci lub niezawodno\u015bci \u2013 warto spojrze\u0107 na architektur\u0119 event\u00f3w pod tym k\u0105tem. W JurskiTech.pl pomagamy firmom projektowa\u0107 systemy, kt\u00f3re rosn\u0105 bez b\u00f3lu. A je\u015bli masz w\u0105tpliwo\u015bci \u2013 przyjd\u017a z kodem, pogadamy.<\/p>\n","protected":false},"excerpt":{"rendered":" Dlaczego Tw\u00f3j SaaS traci na z\u0142ej architekturze event\u00f3w? 3 lekcje z backendu Event-driven architecture (EDA) brzmi jak odpowied\u017a na wszystkie problemy skalowalno\u015bci. W teorii \u2013 asynchroniczno\u015b\u0107, lu\u017ane powi\u0105zania, \u0142atwe dodawanie nowych funkcji. W praktyce \u2013 widzia\u0142em ju\u017c kilka system\u00f3w, kt\u00f3re po wdro\u017ceniu EDA generowa\u0142y wi\u0119cej problem\u00f3w ni\u017c rozwi\u0105zywa\u0142y. Cz\u0119sto s\u0142ysz\u0119 od CTO: \u201eprzeszli\u015bmy na eventy,<\/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":[186,617,584,24],"class_list":["post-1936","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-architektura-systemow","tag-b2b-saas","tag-event-driven-architecture","tag-skalowalnosc"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1936","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=1936"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1936\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=1936"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=1936"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=1936"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}1. Utrata kolejno\u015bci event\u00f3w \u2013 cichy zab\u00f3jca sp\u00f3jno\u015bci danych<\/h3>\n
2. Brak idempotentno\u015bci \u2013 podw\u00f3jne op\u0142aty i zduplikowane maile<\/h3>\n
3. Eventy zbyt szczeg\u00f3\u0142owe lub zbyt og\u00f3lne \u2013 balans mi\u0119dzy granularno\u015bci\u0105 a kosztem<\/h3>\n
Podsumowanie<\/h3>\n