Architektura zdarzeniowa (event-driven) brzmi kusz\u0105co \u2013 obiecuje elastyczno\u015b\u0107, skalowalno\u015b\u0107 i lu\u017ane powi\u0105zania mi\u0119dzy serwisami. W e-commerce, gdzie ka\u017cda sekunda przestoju kosztuje sprzeda\u017c, wydaje si\u0119 by\u0107 \u015bwi\u0119tym Graalem. Ale diabe\u0142 tkwi w szczeg\u00f3\u0142ach.<\/p>\n
Widz\u0119 to w projektach, do kt\u00f3rych wchodz\u0119 jako konsultant: zespo\u0142y skacz\u0105 na event-driven z entuzjazmem, a po p\u00f3\u0142 roku maj\u0105 piek\u0142o na ziemi. Przeanalizuj\u0119 trzy konkretne b\u0142\u0119dy, kt\u00f3re regularnie powtarzaj\u0105 ma\u0142e i \u015brednie firmy. Bez teorii, tylko praktyka.<\/p>\n
Zaczyna si\u0119 niewinnie. Kto\u015b rzuca: \u201eRobimy event-driven, wi\u0119c ka\u017cda zmiana stanu to zdarzenie\u201d. I nagle masz zdarzenia Problem? Po trzech miesi\u0105cach nikt nie wie, kt\u00f3re zdarzenia s\u0105 krytyczne, a kt\u00f3re to tylko szum. Zaczynasz \u0142apa\u0107 wszystko, \u017ceby niczego nie przegapi\u0107. W efekcie masz szambo, nie system.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Klient \u2013 sklep z butami, 50 tys. zam\u00f3wie\u0144 miesi\u0119cznie. Zesp\u00f3\u0142 zdefiniowa\u0142 120 typ\u00f3w zdarze\u0144. System dzia\u0142a\u0142 wolno, bo ka\u017cdy serwis subskrybowa\u0142 tony niepotrzebnych komunikat\u00f3w. Po audycie zostawili 12 zdarze\u0144 biznesowych. Wydajno\u015b\u0107 wzros\u0142a 4-krotnie.<\/p>\n Jak to naprawi\u0107?<\/strong> Zdarzenia powinny odzwierciedla\u0107 fakty biznesowe, nie techniczne. Ka\u017cde zdarzenie to co\u015b, co ma znaczenie dla domeny \u2013 W architekturze zdarzeniowej gwarancja dostarczenia komunikatu \u201edok\u0142adnie raz\u201d jest iluzj\u0105. W praktyce dostajesz \u201eco najmniej raz\u201d. Brak idempotentno\u015bci to prosta droga do katastrofy.<\/p>\n Wyobra\u017a sobie: klient sk\u0142ada zam\u00f3wienie, system wystawia event Przyk\u0142ad z \u017cycia:<\/strong> Firma sprzedaj\u0105ca bilety. Podczas promocji czarna pizza \u2013 system zduplikowa\u0142 zam\u00f3wienia. Sprzedali dwa razy wi\u0119cej bilet\u00f3w ni\u017c mieli. Chaos, zwroty, kryzys komunikacyjny.<\/p>\n Jak to naprawi\u0107?<\/strong> Ka\u017cda us\u0142uga przetwarzaj\u0105ca zdarzenie musi by\u0107 idempotentna. Najprostszy spos\u00f3b: nadaj zdarzeniom unikalne ID i przechowuj je po stronie odbiorcy w bazie (np. z indeksem unique). Przed przetworzeniem sprawdzasz, czy ju\u017c to widzia\u0142e\u015b. Koszt ma\u0142y, zysk ogromny.<\/p>\n Przy architekturze synchronicznej (REST) wiesz, kt\u00f3ry serwis pad\u0142 i gdzie szuka\u0107 log\u00f3w. Przy event-driven jest jak w czarnej skrzynce \u2013 zdarzenie p\u0142ynie przez kilka serwis\u00f3w, ka\u017cdy co\u015b robi, a je\u015bli co\u015b p\u00f3jdzie \u017ale, nie wiadomo, gdzie szuka\u0107.<\/p>\n Zespo\u0142y cz\u0119sto nie my\u015bl\u0105 o tym na pocz\u0105tku. Dopiero gdy pojawia si\u0119 bug, sp\u0119dzaj\u0105 dni na szukaniu, kt\u00f3ry serwis zgubi\u0142 event. A klienci czekaj\u0105 na zam\u00f3wienia.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> E-commerce z mod\u0105. Wdro\u017cyli event-driven dla aktualizacji stan\u00f3w magazynowych. Po dw\u00f3ch tygodniach zacz\u0119\u0142y si\u0119 problemy \u2013 klienci kupowali rzeczy, kt\u00f3re by\u0142y w koszyku innych. Debugowanie trwa\u0142o tydzie\u0144. Okaza\u0142o si\u0119, \u017ce jeden serwis nie przetwarza\u0142 zdarze\u0144 w kolejno\u015bci, powoduj\u0105c race condition. Bez odpowiedniego \u015bledzenia (distributed tracing) znalezienie tego zaj\u0119\u0142o wieczno\u015b\u0107.<\/p>\n Jak to naprawi\u0107?<\/strong> Od dnia 1 u\u017cywaj narz\u0119dzi do distributed tracing (np. Jaeger, Zipkin). Ka\u017cde zdarzenie powinno nie\u015b\u0107 ze sob\u0105 unikalny identyfikator korelacji (correlation ID). Dodaj te\u017c logowanie strukturalne i metryki (np. op\u00f3\u017anienia przetwarzania, liczba zdarze\u0144 w kolejce). To nie jest opcja \u2013 to konieczno\u015b\u0107.<\/p>\n Architektura zdarzeniowa w e-commerce ma sens \u2013 szczeg\u00f3lnie gdy masz wiele serwis\u00f3w komunikuj\u0105cych si\u0119 asynchronicznie. Ale bez zdyscyplinowania w definiowaniu zdarze\u0144, dba\u0142o\u015bci o idempotentno\u015b\u0107 i solidnego monitoringu, zamienia si\u0119 w koszmar.<\/p>\n Zanim rzucisz si\u0119 w wir implementacji, zadaj sobie trzy pytania: Czy moje zdarzenia s\u0105 naprawd\u0119 biznesowe? Czy ka\u017cdy odbiorca jest idempotentny? Czy mam narz\u0119dzia do debugowania z\u0142o\u017conych przep\u0142yw\u00f3w? Je\u015bli cho\u0107 na jedno odpowied\u017a brzmi \u201enie\u201d \u2013 zatrzymaj si\u0119. Lepiej spowolni\u0107 teraz, ni\u017c gasi\u0107 po\u017cary p\u00f3\u017aniej.<\/p>\n JurskiTech specjalizuje si\u0119 w projektowaniu architektury zdarzeniowej odpornej na b\u0142\u0119dy. Je\u015bli potrzebujesz audytu lub wsparcia wdro\u017ceniowego \u2013 daj zna\u0107.<\/p>\n","protected":false},"excerpt":{"rendered":" Architektura zdarzeniowa (event-driven) brzmi kusz\u0105co \u2013 obiecuje elastyczno\u015b\u0107, skalowalno\u015b\u0107 i lu\u017ane powi\u0105zania mi\u0119dzy serwisami. W e-commerce, gdzie ka\u017cda sekunda przestoju kosztuje sprzeda\u017c, wydaje si\u0119 by\u0107 \u015bwi\u0119tym Graalem. Ale diabe\u0142 tkwi w szczeg\u00f3\u0142ach. Widz\u0119 to w projektach, do kt\u00f3rych wchodz\u0119 jako konsultant: zespo\u0142y skacz\u0105 na event-driven z entuzjazmem, a po p\u00f3\u0142 roku maj\u0105 piek\u0142o na ziemi.<\/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":[776,476,584,24],"class_list":["post-2545","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-ai-e-commerce","tag-architektura-zdarzeniowa","tag-event-driven-architecture","tag-skalowalnosc"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2545","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=2545"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2545\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2545"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2545"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2545"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}orderCreated<\/code>, orderUpdated<\/code>, orderConfirmed<\/code>, orderPacked<\/code>, orderShipped<\/code>, orderDelivered<\/code>, a do tego paymentReceived<\/code>, paymentFailed<\/code>, paymentRefunded<\/code>\u2026 lista ro\u015bnie.<\/p>\norderPlaced<\/code>, paymentSettled<\/code>, stockExhausted<\/code>. Reszta to implementacja, kt\u00f3ra nie musi by\u0107 rozg\u0142aszana.<\/p>\n2. Zapomnienie o idempotentno\u015bci<\/h2>\n
orderPlaced<\/code>. Broker (np. Kafka czy RabbitMQ) z przyczyn sieciowych wy\u015ble go dwa razy. Je\u015bli Twoja us\u0142uga p\u0142atno\u015bci nie sprawdzi duplikatu, obci\u0105\u017cy kart\u0119 podw\u00f3jnie. Klient wpada w furi\u0119, chargeback, z\u0142a opinia.<\/p>\n3. Brak strategii debugowania i monitorowania<\/h2>\n
Podsumowanie<\/h2>\n