Architektura event-driven w praktyce

Jak projektować zdarzeniowe systemy mikroserwisowe bez utraty spójności i kontroli nad przepływem danych.

Jakub Merta30 lis 20259 min czytaniaArchitektura

#event-driven#mikroserwisy#komunikaty#architektura

Podsumowanie

Szybki przegląd tego, jak projektować architekturę event-driven bez utraty spójności, jak dobierać kontrakty zdarzeń i gdzie najczęściej pojawiają się pułapki.

Najwazniejsze wnioski

Traktuj kontrakty zdarzeń jak publiczne API i wersjonuj je od początku.
Projektuj idempotentne konsumenty i buduj reprocessing jako standard.
Rozdziel część komunikacyjną od logiki domeny, by łatwiej testować i skalić.
Dobierz broker i model dostarczeń do wymagań biznesowych, nie do mody.

Architektura event-driven w praktyce

Podejście event-driven upraszcza integracje między usługami, ale wymaga dyscypliny. Największym ryzykiem jest chaos semantyczny: różne zespoły publikują zdarzenia o zbliżonych nazwach, lecz odmiennym znaczeniu.

Trzy zasady projektowe

Jasne kontrakty – każde zdarzenie ma schemat w repozytorium (np. OpenAPI/AsyncAPI) i numerowaną wersję.
Idempotencja – konsumenci muszą obsłużyć duplikaty; zapisuj eventId w tabeli przetworzeń lub używaj ON CONFLICT DO NOTHING.
Dead-letter first – od początku planuj kolejki DLQ z metrykami; brak tego utrudnia inspekcję produkcji.

Przykład strumienia zamówień

Rendering diagram...

W powyższym scenariuszu krytyczne jest ustalenie, które zdarzenie kończy workflow. Często jest to PaymentCaptured, a nie OrderCreated, co wpływa na UX i SLA.

Monitorowanie

Śledź przepływ przez korelację traceId między zdarzeniami, a nie tylko orderId. Dzięki temu widzisz, gdzie ginie komunikat, nawet jeśli numer zamówienia nie został jeszcze wygenerowany.