Wyobra\u017a sobie aplikacj\u0119, w kt\u00f3rej ka\u017cde dzia\u0142anie u\u017cytkownika wyzwala natychmiastow\u0105 reakcj\u0119 systemu \u2013 bez op\u00f3\u017anie\u0144, bez zb\u0119dnych zapyta\u0144 do bazy, bez przeci\u0105\u017cania serwera. Brzmi jak marzenie? Dla wielu firm to codzienno\u015b\u0107 dzi\u0119ki Event-Driven Architecture (EDA)<\/strong>. Jednak wi\u0119kszo\u015b\u0107 projekt\u00f3w wci\u0105\u017c opiera si\u0119 na synchronicznych \u0142a\u0144cuchach wywo\u0142a\u0144, kt\u00f3re przy skali zaczynaj\u0105 dusi\u0107 biznes.<\/p>\n W tym artykule przyjrzymy si\u0119 trzem konkretnym b\u0142\u0119dom, kt\u00f3re pope\u0142niaj\u0105 zespo\u0142y backendowe przy implementacji EDA, oraz poka\u017c\u0119, jak ich unikn\u0105\u0107. Nie b\u0119dzie teorii oderwanej od rzeczywisto\u015bci \u2013 same lekcje z ognia.<\/p>\n Problem<\/strong> Przyk\u0142ad z \u017cycia<\/strong> Rozwi\u0105zanie<\/strong> Biznesowa konsekwencja<\/strong> Problem<\/strong> Przyk\u0142ad z \u017cycia<\/strong> Rozwi\u0105zanie<\/strong> Biznesowa konsekwencja<\/strong> Problem<\/strong> Przyk\u0142ad z \u017cycia<\/strong> Rozwi\u0105zanie<\/strong> Biznesowa konsekwencja<\/strong> Event-Driven Architecture to pot\u0119\u017cne narz\u0119dzie, ale wymaga dojrza\u0142o\u015bci technicznej i przemy\u015blanego projektowania. Unikaj\u0105c trzech opisanych b\u0142\u0119d\u00f3w \u2013 braku idempotentno\u015bci, zbytniego powi\u0105zania event\u00f3w z implementacj\u0105 oraz pomijania monitoringu \u2013 mo\u017cesz zbudowa\u0107 system, kt\u00f3ry skaluje si\u0119 p\u0142ynnie i jest odporny na awarie.<\/p>\n W JurskiTech wdra\u017camy EDA w projektach naszych klient\u00f3w od lat. Wiemy, \u017ce diabe\u0142 tkwi w szczeg\u00f3\u0142ach. Je\u015bli planujesz migracj\u0119 lub chcesz sprawdzi\u0107, czy Tw\u00f3j system nie pope\u0142nia tych b\u0142\u0119d\u00f3w \u2013 skontaktuj si\u0119 z nami. Pomo\u017cemy Ci unikn\u0105\u0107 kosztownych pu\u0142apek.<\/p>\n","protected":false},"excerpt":{"rendered":" Wst\u0119p Wyobra\u017a sobie aplikacj\u0119, w kt\u00f3rej ka\u017cde dzia\u0142anie u\u017cytkownika wyzwala natychmiastow\u0105 reakcj\u0119 systemu \u2013 bez op\u00f3\u017anie\u0144, bez zb\u0119dnych zapyta\u0144 do bazy, bez przeci\u0105\u017cania serwera. Brzmi jak marzenie? Dla wielu firm to codzienno\u015b\u0107 dzi\u0119ki Event-Driven Architecture (EDA). Jednak wi\u0119kszo\u015b\u0107 projekt\u00f3w wci\u0105\u017c opiera si\u0119 na synchronicznych \u0142a\u0144cuchach wywo\u0142a\u0144, kt\u00f3re przy skali zaczynaj\u0105 dusi\u0107 biznes. W tym artykule<\/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":[52,556,654,24],"class_list":["post-1914","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-aplikacje-webowe","tag-architektura-backend","tag-event-driven-architecture-2","tag-skalowalnosc"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1914","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=1914"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/1914\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=1914"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=1914"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=1914"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}1. Brak w\u0142a\u015bciwej obs\u0142ugi niepowodze\u0144: zak\u0142adanie, \u017ce event zawsze dotrze<\/h2>\n
\nW architekturze synchronicznej b\u0142\u0119dy s\u0105 oczywiste \u2013 je\u015bli serwis A nie odpowie, serwis B dostaje timeout i mo\u017ce podj\u0105\u0107 akcj\u0119. W EDA zak\u0142adamy, \u017ce eventy s\u0105 niezawodne, ale to z\u0142udne. Twoja kolejka mo\u017ce si\u0119 zapcha\u0107, broker mo\u017ce pa\u015b\u0107, a event mo\u017ce zosta\u0107 przetworzony dwukrotnie.<\/p>\n
\nJeden z naszych klient\u00f3w, platforma SaaS do zarz\u0105dzania subskrypcjami, wdro\u017cy\u0142 EDA do obs\u0142ugi p\u0142atno\u015bci. Gdy klient dokona\u0142 p\u0142atno\u015bci, wysy\u0142ali event do serwisu aktywuj\u0105cego dost\u0119p. Niestety, z powodu braku idempotentno\u015bci eventu, kilkukrotne wys\u0142anie tego samego zdarzenia (np. po restarcie kolejki) skutkowa\u0142o wielokrotnym odnowieniem subskrypcji na kilka dni. Klienci dostawali dost\u0119p za darmo, a firma traci\u0142a przychody.<\/p>\n
\nKa\u017cdy event powinien mie\u0107 niepowtarzalny identyfikator (np. UUID), a serwis konsumuj\u0105cy musi by\u0107 idempotentny \u2013 czyli przetworzenie tego samego eventu dwa razy daje ten sam skutek. Dodatkowo warto implementowa\u0107 dead letter queue (DLQ) dla event\u00f3w, kt\u00f3re nie mog\u0105 zosta\u0107 przetworzone, a nie po prostu je ignorowa\u0107.<\/p>\n
\nBrak obs\u0142ugi b\u0142\u0119d\u00f3w w EDA prowadzi do utraty pieni\u0119dzy (niew\u0142a\u015bciwe naliczenia), z\u0142ego UX (np. zduplikowane zam\u00f3wienia) i utraty zaufania. Wdro\u017cenie idempotentno\u015bci i DLQ to inwestycja, kt\u00f3ra zwraca si\u0119 przy pierwszym powa\u017cnym b\u0142\u0119dzie.<\/p>\n2. Zbyt silne powi\u0105zanie event\u00f3w z konkretnymi serwisami<\/h2>\n
\nCz\u0119sty b\u0142\u0105d: tworzenie event\u00f3w, kt\u00f3re s\u0105 \u015bci\u015ble powi\u0105zane z implementacj\u0105 konkretnych us\u0142ug. Przyk\u0142adowo, event orderPlaced<\/code> niesie ze sob\u0105 ca\u0142y obiekt zam\u00f3wienia wraz z danymi klienta, produktami i cenami. Gdy zmienisz struktur\u0119 zam\u00f3wienia, musisz zaktualizowa\u0107 wszystkich konsument\u00f3w. To zaprzecza idei lu\u017anego sprz\u0119\u017cenia.<\/p>\n
\nPracowa\u0142em kiedy\u015b nad platform\u0105 e-commerce, gdzie zesp\u00f3\u0142 wysy\u0142a\u0142 w evencie pe\u0142en obiekt zam\u00f3wienia. Gdy dodali\u015bmy pole discountCode<\/code>, ka\u017cdy konsument musia\u0142 zosta\u0107 zaktualizowany, bo niekt\u00f3re serwisy nie by\u0142y przygotowane na nowe pole. Dosz\u0142o do b\u0142\u0119d\u00f3w deserializacji, a proces zam\u00f3wie\u0144 zosta\u0142 zablokowany na kilka godzin.<\/p>\n
\nEventy powinny by\u0107 jak najbardziej og\u00f3lne i zawiera\u0107 tylko niezb\u0119dne dane. Lepiej wys\u0142a\u0107 event order.placed<\/code> z identyfikatorem zam\u00f3wienia, a konsumenci niech sami pobior\u0105 potrzebne szczeg\u00f3\u0142y (np. przez API). Albo jeszcze lepiej: u\u017cyj event\u00f3w wzbogaconych o dane, kt\u00f3re s\u0105 stabilne i niezmienne w czasie (np. timestamp, typ zdarzenia).<\/p>\n
\nZbytnia zale\u017cno\u015b\u0107 od konkretnych danych w eventach spowalnia rozw\u00f3j. Ka\u017cda zmiana w modelu wymaga zmian w wielu serwisach. To zwi\u0119ksza czas wprowadzania nowych funkcji i ryzyko b\u0142\u0119d\u00f3w produkcyjnych. W d\u0142u\u017cszej perspektywie firma traci przewag\u0119 konkurencyjn\u0105.<\/p>\n3. Pomijanie monitoringu i observability w EDA<\/h2>\n
\nW synchronicznej komunikacji \u0142atwo \u015bledzi\u0107 przep\u0142yw \u2013 wystarczy logi i narz\u0119dzia APM. W EDA eventy p\u0142yn\u0105 przez kolejki, a ich przetwarzanie jest asynchroniczne. Bez odpowiedniego monitoringu nie wiesz, czy event zosta\u0142 przetworzony, utkn\u0105\u0142 w kolejce, czy mo\u017ce przepad\u0142.<\/p>\n
\nKlient z bran\u017cy logistycznej wdro\u017cy\u0142 EDA do \u015bledzenia przesy\u0142ek. Po miesi\u0105cu okaza\u0142o si\u0119, \u017ce cz\u0119\u015b\u0107 event\u00f3w dotycz\u0105cych zmiany statusu \u2013 np. „przesy\u0142ka dostarczona” \u2013 by\u0142a gubiona w przypadku przeci\u0105\u017cenia systemu. Klienci nie dostawali powiadomie\u0144, a support by\u0142 zalewany zapytaniami. Firma straci\u0142a reputacj\u0119.<\/p>\n
\nKa\u017cdy event powinien by\u0107 logowany na wej\u015bciu i wyj\u015bciu z systemu. Korzystaj z narz\u0119dzi do observability (np. OpenTelemetry), kt\u00f3re pozwalaj\u0105 \u015bledzi\u0107 eventy przez ca\u0142y \u0142a\u0144cuch. Ustaw alerty na op\u00f3\u017anienia w kolejkach, liczby nieprzetworzonych event\u00f3w oraz b\u0142\u0119dy w DLQ.<\/p>\n
\nBrak widoczno\u015bci w EDA prowadzi do cichych b\u0142\u0119d\u00f3w, kt\u00f3re kumuluj\u0105 si\u0119 i wybuchaj\u0105 w najmniej oczekiwanym momencie. Klienci trac\u0105 zaufanie, a zesp\u00f3\u0142 sp\u0119dza godziny na debugowaniu. Monitoring to nie opcja \u2013 to konieczno\u015b\u0107.<\/p>\nPodsumowanie<\/h2>\n