Event-Driven Architecture

Event Producer

Generuje zdarzenia przy każdej istotnej akcji biznesowej

Przykłady: Serwis zamówień, serwis użytkowników, serwis płatności

Message Broker

Pośrednik przechowujący i routing zdarzeń między producentami a konsumentami

Przykłady: Apache Kafka, RabbitMQ, AWS SQS/SNS, Google Pub/Sub

Event Consumer

Subskrybuje zdarzenia i wykonuje logikę biznesową po ich otrzymaniu

Przykłady: Serwis powiadomień, serwis raportów, serwis ML

Event Schema Registry

Centralne repozytorium schematów zdarzeń — zapewnia kompatybilność

Przykłady: Confluent Schema Registry, AWS Glue, Apicurio

Dead Letter Queue (DLQ)

Kolejka dla zdarzeń które nie mogły być przetworzone po N próbach retry

Przykłady: Kafka DLQ, SQS DLQ, RabbitMQ Dead Letter Exchange

Saga Pattern

Długa transakcja jako seria małych kroków z kompensacją przy błędzie. Choreography lub Orchestration.

Outbox Pattern

Zapis zdarzenia do tabeli 'outbox' w tej samej transakcji co dane. Osobny proces wysyła do brokera.

Event Sourcing

Stan aplikacji jako sekwencja zdarzeń. Replay zdarzeń = odtworzenie stanu.

Fan-out / Pub-Sub

Jedno zdarzenie dostarczone do wielu niezależnych konsumentów równocześnie.

Co to jest Event-Driven Architecture (EDA)?

Event-Driven Architecture (architektura sterowana zdarzeniami) to wzorzec projektowania systemów w którym komponenty komunikują się przez zdarzenia (events) zamiast przez bezpośrednie wywołania API. Zdarzenie (event) to fakta o tym co się wydarzyło: 'OrderPlaced', 'PaymentProcessed', 'UserRegistered'. Kluczowe cechy EDA: Loose coupling — producent zdarzeń nie wie kto je konsumuje. Asynchroniczność — producent wysyła zdarzenie i nie czeka na odpowiedź. Skalowalność — konsumenci mogą być skalowani niezależnie. Audit log — stream zdarzeń jest naturalną historią tego co się wydarzyło. Komponenty EDA: Event Producer — generuje zdarzenia (np. serwis zamówień emituje OrderPlaced). Event Broker — pośrednik przekazujący zdarzenia (Kafka, RabbitMQ, AWS SNS/SQS). Event Consumer — odbiera i przetwarza zdarzenia (np. serwis płatności, serwis powiadomień, serwis raportów). EDA jest fundamentem mikroserwisów i systemów wysokiej skali.

EDA vs. REST API — kiedy co stosować?

REST API vs. Event-Driven Architecture: REST API (synchroniczne): Bezpośrednie wywołanie — serwis A wywołuje serwis B i czeka na odpowiedź. Prostota — łatwy debugging, czytelny flow. Tight coupling — serwis A musi znać adres serwisu B. Single point of failure — jeśli B jest niedostępny, A fail-uje. Kiedy REST: operacje CRUD, gdy potrzebujesz natychmiastowej odpowiedzi (weryfikacja, obliczenia), małe systemy. EDA (asynchroniczne): Loose coupling — producent nie zna konsumentów. Resilience — jeśli konsument jest offline, zdarzenia czekają w kolejce. Skalowalność — możesz dodać nowych konsumentów bez zmian w producencie. Złożoność — trudniejszy debugging, eventual consistency. Kiedy EDA: procesy wieloetapowe (order processing, onboarding), powiadomienia, integracje z zewnętrznymi systemami, operacje które mogą być retry'd, audit logging. Praktyka: większość systemów używa obu — REST dla synchronicznych operacji, EDA dla asynchronicznych workflow.

Czym są Apache Kafka, RabbitMQ i AWS SNS/SQS?

Popularne message brokers: Apache Kafka — distributed log o ogromnej przepustowości. Retencja wiadomości (tygodnie/miesiące), event sourcing, stream processing. Używany przez Netflix, LinkedIn, Uber. Idealny dla high-volume event streams i data pipelines. RabbitMQ — tradycyjna kolejka wiadomości. Routing, priorities, dead-letter queues. Prostszy niż Kafka, świetny dla task queues i RPC patterns. AWS SQS — managed queue service. Simple, reliable, scalable. SQS Standard (at-least-once), SQS FIFO (exactly-once, ordered). AWS SNS — pub/sub service. Fan-out do wielu SQS/Lambda/HTTP. Świetny do powiadomień i multi-subscriber patterns. Google Pub/Sub — managed, globalny, dobra integracja z GCP. Azure Service Bus — managed, enterprise features, DLQ, sessions. Jak wybrać: Potrzebujesz event sourcing i dużej przepustowości? Kafka. Proste task queues? RabbitMQ. Budujesz na AWS? SQS/SNS. Prostota managed service? Odpowiedni cloud provider service.

Co to jest Event Sourcing?

Event Sourcing to wzorzec gdzie zamiast przechowywać aktualny stan aplikacji w bazie danych, przechowujesz sekwencję zdarzeń które do tego stanu doprowadziły. Tradycyjne podejście: UPDATE orders SET status='shipped' WHERE id=123. Tracisz historię — nie wiesz co było wcześniej. Event Sourcing: zapisujesz: OrderCreated, OrderPaid, OrderShipped. Stan = replay wszystkich zdarzeń. Zalety Event Sourcing: Pełen audit log — wiesz co, kiedy i dlaczego się wydarzyło. Time travel — możesz odtworzyć stan systemu z dowolnego momentu w przeszłości. Debugging — replay zdarzeń ujawnia co poszło nie tak. Decoupling — dodajesz projekcje (read models) bez zmiany event store. Wady: Złożoność — snapshot pattern dla długich historii. Eventual consistency — projekcje mogą być za starą. Schema evolution — trudna zmiana formatu starych zdarzeń. Często łączone z CQRS. Narzędzia: EventStoreDB, Kafka jako event store, Axon Framework.

Jakie są wzorce i wyzwania EDA?

Wzorce EDA: Saga Pattern — koordynacja długich transakcji przez serię zdarzeń z kompensacją przy błędzie. Np. order flow: reserve inventory -> charge card -> ship -> lub rollback. Outbox Pattern — gwarantuje że zdarzenie zostanie opublikowane razem z transakcją DB. Eliminuje problem 'zapisałem do DB ale nie wysłałem eventu'. CQRS + Event Sourcing — naturalne połączenie. Commands generują zdarzenia, zdarzenia budują read models. Choreography vs. Orchestration — w choreografii każdy serwis reaguje na zdarzenia autonomicznie (decentralizacja). W orchestracji jeden serwis (orchestrator/saga) koordynuje flow. Wyzwania EDA: Eventual consistency — nie ma transakcji ACID między serwisami. Ordering — zdarzenia mogą przyjść w złej kolejności. At-least-once delivery — może przyjść duplikat eventu (idempotentność konsumenta). Debugging — trudno śledzić flow przez wiele serwisów (potrzeba distributed tracing: Jaeger, Zipkin). Dead Letter Queue — obsługa zdarzeń które nie mogą być przetworzone.

Wyślij zapytanie