Pracowa\u0142em ostatnio z klientem, kt\u00f3ry prowadzi sklep e-commerce z kilkudziesi\u0119cioma tysi\u0105cami transakcji dziennie. Wszystko dzia\u0142a\u0142o dobrze \u2013 do czasu gdy wprowadzili kilka nowych integracji: p\u0142atno\u015bci BNPL, system lojalno\u015bciowy, zewn\u0119trzny fulfillment. Nagle czas odpowiedzi API zacz\u0105\u0142 rosn\u0105\u0107, a w szczycie pojawia\u0142y si\u0119 timeouty. Klient by\u0142 przekonany, \u017ce to wina hostingu. Po audycie okaza\u0142o si\u0119, \u017ce problemem by\u0142a architektura: ka\u017cda operacja wywo\u0142ywa\u0142a szereg synchronicznych zale\u017cno\u015bci, kt\u00f3re blokowa\u0142y g\u0142\u00f3wny w\u0105tek.<\/p>\n
Rozwi\u0105zaniem by\u0142a architektura event-driven. Ale czy ka\u017cda implementacja ko\u0144czy si\u0119 sukcesem? Niestety nie. Widzia\u0142em wiele firm, kt\u00f3re wdro\u017cy\u0142y event-driven i\u2026 wpad\u0142y w nowe pu\u0142apki. W tym artykule poka\u017c\u0119 3 najcz\u0119stsze b\u0142\u0119dy, kt\u00f3re zabijaj\u0105 skalowalno\u015b\u0107 w e-commerce.<\/p>\n
Zanim przejdziemy do b\u0142\u0119d\u00f3w \u2013 kr\u00f3tkie przypomnienie. W architekturze event-driven zamiast wywo\u0142ywa\u0107 us\u0142ugi synchronicznie (np. po z\u0142o\u017ceniu zam\u00f3wienia wywo\u0142ujemy system magazynowy, potem p\u0142atno\u015bci, potem wysy\u0142k\u0119), generujemy zdarzenie (np. \u201eorder.placed\u201d) i wysy\u0142amy je do brokera (np. Kafka, RabbitMQ, AWS EventBridge). Ka\u017cda us\u0142uga subskrybuje interesuj\u0105ce j\u0105 zdarzenia i reaguje asynchronicznie.<\/p>\n
Dzi\u0119ki temu system staje si\u0119 lu\u017ano powi\u0105zany, \u0142atwiej skalowalny i bardziej odporny na awarie. Ale diabe\u0142 tkwi w szczeg\u00f3\u0142ach.<\/p>\n
To najbardziej klasyczny b\u0142\u0105d. Firma wdra\u017ca event-driven, ale w handlerach zdarze\u0144 nadal wykonuje synchroniczne zapytania do innych us\u0142ug. Na przyk\u0142ad: po zdarzeniu \u201eorder.placed\u201d handler systemu lojalno\u015bciowego potrzebuje danych klienta z bazy CRM. Zamiast wcze\u015bniej wzbogaci\u0107 zdarzenie o dane klienta, handler wykonuje synchroniczny request do CRM. Gdy CRM jest wolny, ca\u0142y event si\u0119 op\u00f3\u017ania. A gdy CRM pada, event si\u0119 gubi.<\/p>\n
Przyk\u0142ad z \u017cycia:<\/strong> Klient z sektora fashion mia\u0142 system, w kt\u00f3rym ka\u017cde zdarzenie \u201eorder.placed\u201d wywo\u0142ywa\u0142o 3 synchroniczne zapytania do r\u00f3\u017cnych serwis\u00f3w. W szczycie sezonu broker event\u00f3w zala\u0142 si\u0119, a kolejka ros\u0142a. Rozwi\u0105zanie? Wzbogacanie event\u00f3w o dane niezb\u0119dne do przetworzenia (enrichment) oraz wprowadzenie dedykowanych widok\u00f3w danych (materialized views) w ka\u017cdej us\u0142udze.<\/p>\n Konsekwencje:<\/strong> Op\u00f3\u017anienia, gubienie event\u00f3w, utrata zam\u00f3wie\u0144. W e-commerce ka\u017cda sekunda zw\u0142oki kosztuje konwersj\u0119.<\/p>\n Event-driven nie oznacza, \u017ce wszystko zawsze dzia\u0142a. Czasami handler nie przetworzy eventu \u2013 b\u0142\u0105d w logice, chwilowa niedost\u0119pno\u015b\u0107 bazy, b\u0142\u0119dne dane. I co wtedy? Wiele firm po prostu loguje b\u0142\u0105d i\u2026 nic nie robi. Albo pr\u00f3buje ponownie w niesko\u0144czono\u015b\u0107, za\u015bmiecaj\u0105c kolejk\u0119.<\/p>\n Prawid\u0142owe podej\u015bcie:<\/strong> Wdro\u017cenie dead letter queue (DLQ) \u2013 osobnej kolejki dla event\u00f3w, kt\u00f3re nie uda\u0142o si\u0119 przetworzy\u0107 po kilku pr\u00f3bach. Nale\u017cy te\u017c okre\u015bli\u0107 polityk\u0119 ponawiania: liczba pr\u00f3b, backoff (np. wyk\u0142adniczy), timeouty. Dodatkowo warto monitorowa\u0107 DLQ i alertowa\u0107, gdy liczba nieudanych event\u00f3w przekracza pr\u00f3g.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Sklep z elektronik\u0105 straci\u0142 5% zam\u00f3wie\u0144, bo eventy \u201epayment.success\u201d nie dociera\u0142y do systemu wysy\u0142kowego. Przyczyn\u0105 by\u0142 b\u0142\u0105d walidacji danych (nieprawid\u0142owy format adresu). Eventy l\u0105dowa\u0142y w black hole \u2013 logowa\u0142y si\u0119, ale nie trafia\u0142y do DLQ. Dopiero po dodaniu DLQ i monitoringu wykryto problem i naprawiono walidacj\u0119.<\/p>\n Konsekwencje:<\/strong> Utrata zam\u00f3wie\u0144, niezrealizowane wysy\u0142ki, spadek reputacji.<\/p>\n W e-commerce cz\u0119sto zdarzenia musz\u0105 by\u0107 przetwarzane w okre\u015blonej kolejno\u015bci. Na przyk\u0142ad: najpierw \u201epayment.pending\u201d, potem \u201epayment.success\u201d, a dopiero potem \u201eorder.shipped\u201d. Je\u015bli kolejno\u015b\u0107 zostanie zachwiana, system mo\u017ce wys\u0142a\u0107 przesy\u0142k\u0119 przed potwierdzeniem p\u0142atno\u015bci.<\/p>\n Architektura event-driven domy\u015blnie nie gwarantuje kolejno\u015bci \u2013 zw\u0142aszcza gdy u\u017cywamy wielu partycji. Rozwi\u0105zaniem jest stosowanie key-based partitioning (np. identyfikator zam\u00f3wienia jako klucz partycji), aby wszystkie eventy dla danego zam\u00f3wienia trafia\u0142y do tej samej partycji i by\u0142y przetwarzane sekwencyjnie. Alternatywnie mo\u017cna u\u017cywa\u0107 dedykowanych narz\u0119dzi do event sourcing lub sagas.<\/p>\n Przyk\u0142ad z \u017cycia:<\/strong> Klient wdro\u017cy\u0142 Kafk\u0119 dla us\u0142ugi p\u0142atno\u015bci. U\u017cyli domy\u015blnego hashowania klucza, ale kluczem by\u0142 UUID zam\u00f3wienia, co rozrzuca\u0142o eventy po wszystkich partycjach. W efekcie przetwarzanie r\u00f3wnoleg\u0142e powodowa\u0142o, \u017ce czasami \u201eorder.shipped\u201d by\u0142 przetwarzany przed \u201epayment.success\u201d. Na szcz\u0119\u015bcie mieli zabezpieczenia w logice biznesowej, ale op\u00f3\u017anienia by\u0142y znaczne.<\/p>\n Konsekwencje:<\/strong> B\u0142\u0119dy logiczne, problemy z transakcjami, trudne do debugowania.<\/p>\n Architektura event-driven to pot\u0119\u017cne narz\u0119dzie, ale wymaga przemy\u015blanego projektu. Oto trzy kluczowe zasady:<\/p>\n W JurskiTech regularnie pomagamy firmom przej\u015b\u0107 na architektur\u0119 event-driven lub poprawi\u0107 istniej\u0105ce implementacje. Cz\u0119sto okazuje si\u0119, \u017ce problem nie le\u017cy w samym narz\u0119dziu, ale w projekcie. Je\u015bli rozwijasz e-commerce i czujesz, \u017ce architektura zaczyna Ci\u0119 ogranicza\u0107 \u2013 warto spojrze\u0107 na ni\u0105 krytycznie. Event-driven mo\u017ce by\u0107 zbawieniem, ale tylko je\u015bli zrobisz to dobrze.<\/p>\n","protected":false},"excerpt":{"rendered":" Wst\u0119p: Kiedy system przestaje nad\u0105\u017ca\u0107 Pracowa\u0142em ostatnio z klientem, kt\u00f3ry prowadzi sklep e-commerce z kilkudziesi\u0119cioma tysi\u0105cami transakcji dziennie. Wszystko dzia\u0142a\u0142o dobrze \u2013 do czasu gdy wprowadzili kilka nowych integracji: p\u0142atno\u015bci BNPL, system lojalno\u015bciowy, zewn\u0119trzny fulfillment. Nagle czas odpowiedzi API zacz\u0105\u0142 rosn\u0105\u0107, a w szczycie pojawia\u0142y si\u0119 timeouty. Klient by\u0142 przekonany, \u017ce to wina hostingu. 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":[776,276,584,24],"class_list":["post-2465","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-ai-e-commerce","tag-architektura-api","tag-event-driven-architecture","tag-skalowalnosc"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2465","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=2465"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2465\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2465"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2465"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2465"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}B\u0142\u0105d #2: Brak strategii na eventy nieudane (failed events)<\/h2>\n
B\u0142\u0105d #3: Niew\u0142a\u015bciwe zarz\u0105dzanie kolejno\u015bci\u0105 event\u00f3w<\/h2>\n
Podsumowanie: Jak unikn\u0105\u0107 tych b\u0142\u0119d\u00f3w?<\/h2>\n
\n