Event-Driven Architecture

Pub/Sub

Publisher emituje event, wielu subscribers reaguje niezależnie. Decoupling producentów od konsumentów.

Kafka, SNS, Google Pub/Sub, RabbitMQ fanout

Event Streaming

Ciągły strumień eventów — konsumenci przetwarzają w czasie rzeczywistym lub batches. Log retention umożliwia replay.

Kafka, Kinesis, Pulsar, Redpanda

Message Queue (Work Queue)

Zadania rozdzielane między pool workerów. Jeden worker per task. Skalowanie workerów niezależnie.

RabbitMQ, SQS, Celery, Bull (Node.js)

Event Sourcing

Stan systemu jako sekwencja eventów. Pełna historia, replay, audit log, czasowe projekcje.

EventStoreDB, Kafka, Axon Framework

CQRS

Oddzielne modele dla zapisu i odczytu. Read models optymalizowane dla query. Write side przez commands.

Axon, MediatR, custom implementation

Saga (Choreography)

Długie transakcje przez eventy. Każdy serwis reaguje na event i emituje kolejny. Brak centralnego koordynatora.

Eventuate, Axon Saga, custom

Co to jest Event-Driven Architecture (EDA) i jak działa?

Event-Driven Architecture (EDA) to styl architektoniczny gdzie komponenty komunikują się przez emisję i reagowanie na zdarzenia (events) zamiast bezpośrednich wywołań (request-response). Fundamentalne koncepty: Event — niezmenny fakt który się wydarzył ('OrderPlaced', 'UserRegistered', 'PaymentFailed'). Zawiera dane zdarzenia i metadane (timestamp, version, correlation ID). Producer — komponent emitujący event. Nie wie kto go konsumuje. Consumer — komponent reagujący na event. Może być wiele konsumentów jednego eventu. Event Broker — pośrednik przechowujący i dostarczający eventy (Kafka, RabbitMQ, SQS). Topologie EDA: Event Notification — powiadamiaj że coś się stało, bez szczegółów. Consumer pobiera dane jeśli potrzebuje. Event-Carried State Transfer — event zawiera pełny stan (dane). Consumer ma wszystko co potrzeba w evencie. Event Sourcing — stan systemu to sekwencja eventów (zamiast snapshot w bazie). CQRS + Event Sourcing — Command Query Responsibility Segregation. Zalety EDA: loose coupling — producer nie zna consumers. Scalability — konsumenci skalują niezależnie. Resilience — failure jednego konsumenta nie blokuje producenta. Audit log — naturalna historia zmian. Wyzwania: eventual consistency — stan spójny po czasie, nie natychmiast. Debugowanie trudniejsze. Duplikaty eventów (at-least-once delivery) — idempotentność konsumenta.

Apache Kafka — jak działa i kiedy używać?

Apache Kafka: rozproszony log zdarzeń (distributed event streaming platform). Architektura Kafka: Topics — named stream of events (jak kategoria). Każdy topic podzielony na Partitions. Partitions: dane rozłożone między partycje. Każda partycja jest ordered log — gwarantuje kolejność w partycji (nie w topicu). Consumer Groups: wiele konsumentów w grupie — każda partycja przypisana do jednego konsumenta w grupie. Brokers: węzły Kafka klastra. Replication factor: każda partycja replikowana na N brokerów. Retention: eventy przechowywane przez określony czas (domyślnie 7 dni) lub rozmiar. Consumer może wczytać historię od początku. Kafka Connect: łączniki do importu/eksportu danych (baza danych, S3, Elasticsearch). Change Data Capture (CDC) przez Debezium. Kafka Streams: biblioteka do przetwarzania strumieni w JVM. Real-time aggregations, joins, transformations. Kiedy Kafka: high-throughput (miliony eventów/sek). Event log jako source of truth. Multiple consumers per topic. Long retention potrzebna. Kafka vs. RabbitMQ: Kafka — log-based, high throughput, retention, replay. RabbitMQ — queue-based, flexible routing, lower throughput. Managed Kafka: Confluent Cloud, AWS MSK, Redpanda (Kafka API-compatible, 10x szybszy), Upstash Kafka (serverless).

Event Sourcing i CQRS — kiedy i jak implementować?

Event Sourcing: zamiast zapisywać aktualny stan w bazie danych, zapisujesz sekwencję eventów które doprowadziły do tego stanu. Aggregate: obiekt domenowy z logiką biznesową. Stan = fold wszystkich eventów w chronologicznej kolejności. Snapshot: co N eventów zapisz snapshot stanu (optymalizacja dla długich historii). Replay: możesz odtworzyć stan systemu na dowolny moment w przeszłości. Audit log gratis — pełna historia zmian. Event Store: EventStoreDB — dedykowana baza dla event sourcing. Kafka jako event store. PostgreSQL + append-only table. CQRS (Command Query Responsibility Segregation): oddziel model zapisu (commands) od modelu odczytu (queries). Write side: commands → domain logic → events. Read side: projections z eventów → optimized read models. Korzyści CQRS + ES: read models mogą być zoptymalizowane (denormalizacja). Scaling read i write niezależnie. Testowanie czystej logiki domenowej. Wyzwania: eventual consistency — read model aktualizowany asynchronicznie. Complexity — nie dla każdej aplikacji. Saga / Process Manager: koordynacja długich transakcji między mikroserwisami. Choreography — serwisy reagują na eventy innych (prostsze, ale trudniejsze do śledzenia). Orchestration — centralny koordynator (Saga manager) wysyła komendy (łatwiej debug). Outbox Pattern: atomowe zapisanie eventu razem z transakcją bazodanową — eliminuje 'dual write' problem.

RabbitMQ i message queues — kiedy zamiast Kafka?

RabbitMQ: broker wiadomości (message broker) oparty na AMQP protokole. Exchanges i Queues: Publisher wysyła do Exchange (nie queue). Exchange routing rules (direct, fanout, topic, headers). Direct: routing key musi pasować dokładnie. Fanout: broadcast do wszystkich podpiętych queues. Topic: routing key z wildcards (#, *). Dead Letter Queue (DLQ): wiadomości które nie mogły być przetworzone idą do DLQ. Po N próbach retry → DLQ → manual inspection. Potwierdzenia (ack): Consumer potwierdzenie po przetworzeniu (message usuwana). Brak ack → message wraca do kolejki (redelivery). Persistence: wiadomości i kolejki mogą być trwałe (przeżyją restart broker). TTL: time-to-live per wiadomość lub kolejkę. Kiedy RabbitMQ zamiast Kafka: potrzebujesz złożonego routingu (exchange patterns). Niższa latency (RabbitMQ szybszy dla małych wiadomości). Wiadomości powinny być usuwane po przetworzeniu (nie log retention). Work queues (task distribution) między workery. Alternatywy i narzędzia cloud: AWS SQS — managed queue, FIFO queues, at-least-once. AWS SNS — pub/sub, fanout do SQS/Lambda/HTTP. Google Pub/Sub — managed, at-least-once, ordering per key. Azure Service Bus — advanced messaging, sessions, transactions. Celery (Python): task queue library używająca RabbitMQ lub Redis jako broker. Asynchroniczne zadania w Django/Flask — email sending, report generation.

Jak wdrożyć Event-Driven Architecture w praktyce — pułapki i dobre praktyki?

Dobre praktyki EDA: Event schema versioning — eventy muszą ewoluować bez breaking changes. Additive changes (nowe opcjonalne pola). Używaj Avro, Protobuf lub JSON Schema z Schema Registry (Confluent Schema Registry). Consumer idempotentność: event może być dostarczony więcej niż raz (at-least-once delivery). Consumer musi być idempotentny — przetworzenie tego samego eventu N razy daje ten sam wynik. Deduplikacja przez event ID + idempotency key. Correlation ID: każdy event powinien nieść correlation ID dla tracingu przez wiele serwisów. Dead Letter Queue: zawsze konfiguruj DLQ dla nieobrabianych wiadomości — bez tego gubisz dane. Circuit breaker: zabezpiecz consumer przed kaskadowymi awariami downstream. Monitoring: lag monitoring — opóźnienie konsumenta (consumer lag w Kafka). Event rate, error rate, DLQ depth. Distributed tracing przez OpenTelemetry. Pułapki: Distributed transactions — nie ma ACID. Używaj Saga pattern + compensating transactions. Eventual consistency — UI może pokazywać stary stan. Dodaj optimistic UI lub polling. Schema coupling — jeśli producer zmienia schemat bez versioning → broken consumers. Ordering — Kafka gwarantuje kolejność w partycji. Dla global ordering: jeden producer, jeden consumer (utrata skalowalności). Testing EDA: contract tests z Pact lub AsyncAPI. Integration tests z embedded Kafka (Testcontainers). Event catalog — dokumentuj wszystkie eventy w organizacji (AsyncAPI standard).

Wyślij zapytanie