Wielu developer\u00f3w i CTO, z kt\u00f3rymi rozmawiam, my\u015bli o architekturze event-driven jak o srebrnej kuli \u2013 rozwi\u0105zaniu na wszystkie problemy ze skalowaniem i responsywno\u015bci\u0105. Rzeczywisto\u015b\u0107 bywa jednak brutalna: bez odpowiedniego projektu, systemy event-driven potrafi\u0105 wygenerowa\u0107 wi\u0119cej chaosu ni\u017c porz\u0105dku. Sp\u00f3jrzmy na to z perspektywy praktyka.<\/p>\n
W klasycznym podej\u015bciu synchronicznym wywo\u0142anie funkcji blokuje w\u0105tek \u2013 im wi\u0119cej zale\u017cno\u015bci, tym wolniej. Event-driven obiecuje asynchroniczno\u015b\u0107: komponent A wysy\u0142a zdarzenie, a B, C czy D mog\u0105 na nie reagowa\u0107, kiedy chc\u0105. Brzmi pi\u0119knie, ale w praktyce pojawiaj\u0105 si\u0119 pytania: kto gwarantuje dostarczenie? co z kolejno\u015bci\u0105? jak debugowa\u0107?<\/p>\n
Zaczynasz od warsztat\u00f3w event storming \u2013 wszyscy naklejaj\u0105 karteczki z nazwami zdarze\u0144. Super pomys\u0142, ale je\u015bli nie zdefiniujesz granic kontekst\u00f3w (bounded contexts), sko\u0144czysz z ogromn\u0105 list\u0105 zdarze\u0144, kt\u00f3re krzy\u017cuj\u0105 si\u0119 bez \u0142adu. Przyk\u0142ad: w systemie e-commerce zdarzenie Lekcja:<\/strong> Zdefiniuj jasne kontrakty dla zdarze\u0144 (schema registry) i ogranicz si\u0119 do jednego zdarzenia na wa\u017cn\u0105 akcj\u0119 biznesow\u0105. U\u017cyj formatu CloudEvents, aby mie\u0107 standard.<\/p>\n W systemie synchronicznym b\u0142\u0105d \u0142atwo z\u0142apa\u0107 i zwr\u00f3ci\u0107 u\u017cytkownikowi. W asynchronicznym zdarzenie znika w brokerze, a je\u015bli konsument go nie przetworzy \u2013 mo\u017ce przepa\u015b\u0107 bez \u015bladu. Widzia\u0142em firm\u0119, kt\u00f3ra straci\u0142a zam\u00f3wienia, bo konsument p\u0142atno\u015bci crashowa\u0142, a zdarzenie nie by\u0142o retryowane.<\/p>\n Lekcja:<\/strong> Ka\u017cdy konsument powinien mie\u0107 mechanizm ponawiania z dead letter queue (DLQ). Monitoruj DLQ i alertuj, gdy pojawi\u0105 si\u0119 w nim wiadomo\u015bci. Nie ufaj, \u017ce broker zrobi wszystko za Ciebie.<\/p>\n Event-driven kusi do tworzenia \u0142a\u0144cuch\u00f3w: A -> B -> C -> D. Je\u015bli jedno ogniwo zawiedzie, ca\u0142y proces staje. Gorzej: je\u015bli B przetwarza zdarzenie, kt\u00f3re publikuje nowe, a C jest subskrybentem, to restart B mo\u017ce wywo\u0142a\u0107 kaskad\u0119.<\/p>\n Lekcja:<\/strong> Stosuj choreografi\u0119 tam, gdzie to mo\u017cliwe, ale w krytycznych procesach rozwa\u017c orkiestracj\u0119 (np. Saga pattern z dedykowanym koordynatorem). Unikaj g\u0142\u0119bokiego zagnie\u017cd\u017cania \u2013 niech zdarzenia raczej wyzwalaj\u0105 niezale\u017cne procesy.<\/p>\n Kiedy\u015b podczas wdro\u017cenia systemu event-driven w sklepie internetowym zauwa\u017cyli\u015bmy, \u017ce zam\u00f3wienia znikaj\u0105. Nie by\u0142o log\u00f3w, bo konsument logowa\u0142 tylko sukces. Okaza\u0142o si\u0119, \u017ce konsument mia\u0142 b\u0142\u0105d w deserializacji i cicho wyrzuca\u0142 zdarzenia. Bez odpowiedniego tracingu siedzieli\u015bmy nad tym dwa dni.<\/p>\n Lekcja:<\/strong> Wprowad\u017a distributed tracing (np. OpenTelemetry) od pierwszego dnia. Ka\u017cde zdarzenie powinno mie\u0107 unikalny identyfikator korelacji. Loguj zar\u00f3wno sukcesy, jak i b\u0142\u0119dy, z poziomem detail.<\/p>\n Nie ka\u017cda aplikacja potrzebuje event-driven. Je\u015bli masz prosty CRUD z jednym u\u017cytkownikiem, to overengineering. Ale je\u015bli skalowanie jest problemem, potrzebujesz integracji wielu system\u00f3w lub d\u0142ugotrwa\u0142ych proces\u00f3w \u2013 event-driven to naturalny wyb\u00f3r. Pami\u0119taj tylko, \u017ce z wi\u0119ksz\u0105 swobod\u0105 idzie wi\u0119ksza odpowiedzialno\u015b\u0107 za monitorowanie i obs\u0142ug\u0119 b\u0142\u0119d\u00f3w.<\/p>\n Architektura event-driven to pot\u0119\u017cne narz\u0119dzie, ale wymaga dyscypliny. Zadbaj o jasne kontrakty, obs\u0142ug\u0119 b\u0142\u0119d\u00f3w, ogranicz zale\u017cno\u015bci i dobre monitorowanie. Wtedy unikniesz chaosu i zyskasz skalowalno\u015b\u0107, kt\u00f3rej oczekujesz. Je\u015bli czujesz, \u017ce Tw\u00f3j system potrzebuje zmiany, ale nie wiesz jak \u2013 warto skonsultowa\u0107 si\u0119 z kim\u015b, kto przeszed\u0142 t\u0119 drog\u0119 kilka razy.<\/p>\n JurskiTech pomaga firmom projektowa\u0107 architektury, kt\u00f3re faktycznie dzia\u0142aj\u0105 w praktyce. Nie sprzedajemy gotowych schemat\u00f3w \u2013 analizujemy Tw\u00f3j kontekst i doradzamy rozwi\u0105zanie szyte na miar\u0119.<\/p>\n","protected":false},"excerpt":{"rendered":" Architektura Event-Driven: jak unikn\u0105\u0107 chaosu w aplikacji? Wielu developer\u00f3w i CTO, z kt\u00f3rymi rozmawiam, my\u015bli o architekturze event-driven jak o srebrnej kuli \u2013 rozwi\u0105zaniu na wszystkie problemy ze skalowaniem i responsywno\u015bci\u0105. Rzeczywisto\u015b\u0107 bywa jednak brutalna: bez odpowiedniego projektu, systemy event-driven potrafi\u0105 wygenerowa\u0107 wi\u0119cej chaosu ni\u017c porz\u0105dku. Sp\u00f3jrzmy na to z perspektywy praktyka. Dlaczego event-driven kusi?<\/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,308,584,379],"class_list":["post-2363","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-architektura-api","tag-back-end","tag-event-driven-architecture","tag-globalne-skalowanie"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2363","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=2363"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2363\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2363"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2363"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2363"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}OrderPlaced<\/code> mo\u017ce interesowa\u0107 magazyn, p\u0142atno\u015bci, marketing, logistyk\u0119. Problem zaczyna si\u0119, gdy ka\u017cda z tych domen zaczyna publikowa\u0107 w\u0142asne zdarzenia na ten sam temat, bez ustalonego formatu.<\/p>\nPu\u0142apka 2: Brak obs\u0142ugi b\u0142\u0119d\u00f3w i retries<\/h3>\n
Pu\u0142apka 3: Zbyt wiele zale\u017cno\u015bci mi\u0119dzy zdarzeniami<\/h3>\n
Pu\u0142apka 4: Debugowanie jak w czarnej skrzynce<\/h3>\n
Kiedy event-driven ma sens?<\/h3>\n
Podsumowanie<\/h3>\n