Architektura EDA
Podstawy EDA

Czym jest architektura event-driven i jak zmienia przepływ danych

Opublikowano: 2026-01-10

Schemat architektury systemu rozproszonego w chmurze
Architektury rozproszone opierają się na wymianie komunikatów między niezależnymi komponentami.

Definicja architektury event-driven

Architektura sterowana zdarzeniami (event-driven architecture, EDA) to wzorzec projektowy, w którym komponenty systemu reagują na zdarzenia — dyskretne fakty opisujące to, co się wydarzyło — zamiast komunikować się poprzez bezpośrednie, synchroniczne wywołania. Producent zdarzenia publikuje je do pośredniczącego kanału, nie wiedząc, kto i w jaki sposób je odbierze.

Taki model odwraca klasyczny kierunek zależności między systemami: zamiast systemu A wołającego wprost system B, system A jedynie ogłasza fakt, a zainteresowane systemy same decydują o reakcji.

Czym jest zdarzenie w tym modelu

Zdarzenie to niezmienny zapis czegoś, co już się wydarzyło — na przykład „zamówienie złożone" albo „stan magazynowy zaktualizowany". W odróżnieniu od polecenia, które wyraża intencję wykonania akcji, zdarzenie opisuje fakt dokonany i nie zakłada, że ktokolwiek na nie zareaguje.

Struktura typowego zdarzenia

Zdarzenie zwykle zawiera identyfikator, znacznik czasu, typ zdarzenia oraz ładunek danych opisujący kontekst — na przykład identyfikator zamówienia i listę pozycji. Struktura ta bywa formalizowana w postaci schematu, aby konsumenci zdarzeń mogli bezpiecznie parsować przychodzące dane.

Porównanie z architekturą żądanie-odpowiedź

W klasycznym modelu żądanie-odpowiedź system wywołujący czeka na odpowiedź systemu wywoływanego, co tworzy bezpośrednią zależność czasową i sieciową między nimi. W modelu event-driven producent zdarzenia nie czeka na żadną odpowiedź — publikacja zdarzenia jest operacją zakończoną w momencie zapisania go w kanale komunikatów.

Typowe zastosowania w systemach korporacyjnych

Wzorzec ten sprawdza się szczególnie tam, gdzie wiele niezależnych systemów musi reagować na te same fakty biznesowe — na przykład gdy złożenie zamówienia powinno jednocześnie wywołać aktualizację magazynu, wysyłkę powiadomienia e-mail i zapis do systemu analitycznego, bez konieczności budowania bezpośrednich integracji między każdą parą systemów.

Powiązane materiały

Message brokers

Message brokers w architekturze EDA — przegląd podejść

Broker komunikatów pośredniczy w przekazywaniu zdarzeń między producentami a konsumentami, zapewniaj…

Wzorce projektowe

Wzorce projektowe stosowane w architekturze sterowanej zdarzeniami

Event sourcing, CQRS i saga to wzorce, które regularnie pojawiają się przy projektowaniu systemów op…

Checklisty

Checklisty przed wdrożeniem architektury event-driven

Zestaw punktów kontrolnych przydatnych przed rozpoczęciem projektowania systemu opartego na zdarzeni…