Wstęp
Zdarzeniowość brzmi jak panaceum na skalowanie. W teorii – system reagujący na zdarzenia, asynchroniczny, elastyczny. W praktyce – widzę startup za startupem, które wpadają w pułapkę „event-driven everything” i kończą z architekturą, która działa tylko w prezentacjach na konferencjach.
Pracowałem przy migracji kilku systemów SaaS do architektury zdarzeniowej. Niektóre odniosły sukces. Inne – po roku przepisały wszystko od nowa. Oto trzy błędy, które widzę najczęściej.
1. Zdarzenia jako broń masowego rażenia
Pierwszy błąd to traktowanie zdarzeń jak uniwersalnego kleju. Zespoły wrzucają wszystko do kolejki: logowanie użytkownika, zmianę statusu zamówienia, kliknięcie w przycisk, a nawet ping serwisu monitorującego. Efekt? System staje się czarną skrzynką, w której nikt nie panuje nad przepływem.
Przykład z życia: Klient – platforma SaaS do zarządzania projektami. Wdrożyli event sourcing, ale każda akcja użytkownika generowała zdarzenie. W szczycie – 50 000 zdarzeń na sekundę. Broker (RabbitMQ) nie dawał rady, konsumenci się dusili. Rozwiązanie? Filtrowanie zdarzeń na wejściu – tylko te istotne dla logiki biznesowej przechodziły dalej.
Konsekwencje dla biznesu: Opóźnienia w przetwarzaniu zamówień, frustracja użytkowników, utrata sprzedaży.
Zasada: Nie każde kliknięcie musi być zdarzeniem. Zdarzenia to komunikaty o faktach, które mają znaczenie dla innych usług. Jeśli nikt nie słucha – nie wysyłaj.
2. Brak gwarancji dostarczenia – czyli „eventy gubią się w drodze”
Drugi błąd to założenie, że wystarczy wysłać zdarzenie, a ono dotrze. W systemie rozproszonym zdarzenia mogą ginąć, duplikować się, zmieniać kolejność. Zespoły często pomijają mechanizmy potwierdzenia (ack), retransmisji lub deduplikacji.
Przykład z życia: Firma e-commerce używała Kafka do obsługi zamówień. Po awarii sieci część zdarzeń zaginęła. Klienci nie otrzymali potwierdzeń, zamówienia zniknęły. Przyczyna? Brak idempotentności konsumentów – po ponownym dostarczeniu zdarzenia system tworzył duplikaty zamówień.
Rozwiązanie: Idempotentne konsumenci, unikalne ID zdarzenia, a w razie potrzeby – transakcyjne outbox (np. tabela w bazie danych, z której dedykowany proces odczytuje i wysyła zdarzenia).
Konsekwencje: Utrata zaufania, koszty zwrotów, ręczna interwencja działu IT.
3. Zdarzenia jako jedyne źródło prawdy – pułapka event sourcingu
Event sourcing – czyli przechowywanie tylko strumienia zdarzeń, z którego odtwarza się stan. Brzmi elegancko, ale w praktyce bywa koszmarem. Zdarzenia są niezmienne, ale schematy danych ewoluują. Bez strategii migracji – po roku masz 100 różnych wersji zdarzeń, a odtworzenie stanu trwa godziny.
Przykład z życia: Startup fintech – event sourcing jako główna warstwa danych. Po zmianie regulacji musieli dodać nowe pole do zdarzenia. Brak backward compatibility – stare zdarzenia przestały pasować. Kod do migracji rósł, a performance spadał. Ostatecznie wprowadzili snapshoty (stan okresowo zapisywany), co skróciło czas odtwarzania z 2 godzin do 5 minut.
Konsekwencje: Wolne raporty, problemy z audytem, blokada developmentu.
Zasada: Event sourcing ma sens, gdy potrzebujesz pełnego audytu lub analizy historycznej. Dla zwykłego CRUD-u – lepiej zostać przy tradycyjnym modelu z opcjonalnym logiem zdarzeń.
Podsumowanie
Architektura zdarzeniowa to potężne narzędzie, ale wymaga dyscypliny. Zanim wrzucisz eventy do swojego SaaS, odpowiedz sobie na trzy pytania:
- Czy każde zdarzenie ma realnego konsumenta?
- Czy konsumenci są odporni na duplikaty i awarie?
- Czy masz plan na ewolucję schematów?
Jeśli odpowiedź na któreś brzmi „nie” – lepiej wrócić do prostszej architektury. Albo zaprosić kogoś z doświadczeniem, kto pomoże uniknąć tych błędów.
W JurskiTech.pl często widzimy firmy, które przepłacają za „modne” rozwiązania, podczas gdy potrzebują solidnego fundamentu. Architektura zdarzeniowa – tak, ale z głową.
