Architektura sterowana zdarzeniami (event-driven)

Architektura sterowana zdarzeniami, często nazywana event-driven, organizuje system wokół zdarzeń. Zdarzenie jest zapisem faktu dokonanego w konkretnym momencie, np. „formularz wysłany”, „płatność potwierdzona” albo „transkrypcja gotowa”. Nie jest poleceniem typu „wyślij mail”. To informacja, na którą jeden lub kilka procesów może zareagować. Dzięki temu źródło zdarzenia nie musi znać wszystkich późniejszych kroków.

W małym biznesie ta różnica jest praktyczna. Formularz na stronie może wysłać zdarzenie o nowym leadzie do n8n przez webhook. Jeden workflow zapisuje kontakt w CRM, drugi kwalifikuje odpowiedź z pomocą AI, trzeci wysyła wewnętrzne powiadomienie. Dodanie czwartego kroku nie wymaga przebudowy formularza. Formularz pozostaje miejscem, które zgłasza fakt, a reguły reakcji żyją w automatyzacjach.

Najprostszy nośnik zdarzenia to webhook, czyli żądanie HTTP wysyłane po wystąpieniu faktu. W większych systemach zdarzenia trafiają także do kolejki lub brokera. Standard CloudEvents opisuje wspólny format danych o zdarzeniu, aby nadawca i odbiorca nie musieli za każdym razem wymyślać innych nazw pól. Niezależnie od transportu przydatne są: typ zdarzenia, identyfikator, czas, źródło oraz dane potrzebne odbiorcy.

Dla systemu AI event-driven oznacza, że model dostaje zadanie we właściwym momencie i z właściwym kontekstem. Po rozmowie sprzedażowej workflow może odebrać gotową transkrypcję, pobrać dane klienta, poprosić model o podsumowanie według ustalonego szablonu, a potem zapisać wynik w źródle prawdy. To lepsze niż okresowe pytanie AI „czy wydarzyło się coś nowego?”, bo ogranicza ręczne sprawdzanie i przypadkowe uruchomienia.

Przykład: kupujący opłaca dostęp do produktu. Zdarzenie payment.succeeded uruchamia workflow, który sprawdza identyfikator płatności, tworzy lub aktualizuje kontakt, przydziela dostęp i zapisuje ślad wykonania. Jeżeli operator płatności ponowi dostawę tego samego webhooka, workflow nie może drugi raz sprzedać dostępu ani wysłać dwóch wiadomości. Dlatego potrzebujesz idempotencji, trwałego identyfikatora zdarzenia i obsługi błędów.

To podejście nie jest automatycznie prostsze. Zdarzenia mogą przyjść dwa razy, w złej kolejności albo z opóźnieniem. Webhook trzeba uwierzytelnić, wrażliwe dane ograniczyć do minimum, a nieudaną pracę kierować do kolejki błędów lub retry. Zacznij od jednego zdarzenia o dużej wartości biznesowej, nazwij je jasno, zapisz log wykonania i ustal, co ma się stać przy drugim identycznym sygnale. Dopiero potem dokładaj AI i kolejne reakcje.