Spójność ostateczna (eventual consistency)

Spójność ostateczna, po angielsku eventual consistency, to właściwość systemu rozproszonego, w którym zmiana nie musi być od razu widoczna we wszystkich miejscach, lecz po zakończeniu synchronizacji repliki dochodzą do zgodnego stanu. Nie oznacza to, że dane mogą być dowolnie niepoprawne. Oznacza, że przez pewien czas różne usługi mogą pokazywać poprzednią i nową wersję tej samej sprawy. Dokumentacja Amazon DynamoDB rozróżnia odczyt silnie spójny, który zwraca aktualny wynik, od odczytu ostatecznie spójnego, który może krótko zwrócić starszą wartość.

W systemie solopreneurki ten wzorzec pojawia się częściej, niż sugeruje techniczna nazwa. Formularz wysyła zdarzenie, narzędzie automatyzacji tworzy kontakt w CRM, CRM uruchamia własną regułę, a platforma e-mailowa aktualizuje segment. Każdy krok może zostać przetworzony osobno. Bezpośrednio po wysłaniu formularza panel może jeszcze nie pokazywać kontaktu, choć zdarzenie zostało przyjęte i jest w kolejce. To różni się od utraty danych. Prawdziwy problem zaczyna się wtedy, gdy człowiek lub kolejne workflow uzna opóźnienie za brak i ponowi akcję bez sprawdzenia identyfikatora zdarzenia.

Praktyczny przykład: klient kupuje dostęp, operator płatności potwierdza transakcję, a webhook ma utworzyć konto i wysłać wiadomość startową. Jeśli po sekundzie CRM nie widzi jeszcze nowego statusu, drugi proces nie powinien tworzyć kolejnego konta. Zamiast pytania „czy rekord już jest?” użyj stabilnego identyfikatora zamówienia i stanu procesu, na przykład „płatność przyjęta, aktywacja w toku”. Po nadejściu potwierdzenia zapis aktualizuje tę samą sprawę. Idempotencja chroni przed duplikatem, a widoczny status chroni użytkownika przed wrażeniem, że system nic nie zrobił.

Spójność ostateczna nie jest usprawiedliwieniem dla niejasnego doświadczenia klienta. Użytkownik nie powinien oglądać pustego ekranu i zgadywać, czy płatność się udała. Pokaż stan przejściowy, komunikat o trwającym przetwarzaniu oraz sposób odzyskania sprawy, jeśli przekroczy sensowny czas. Dla działania o wysokiej stawce, takiego jak pobranie płatności lub nadanie dostępu, źródłem prawdy jest odpowiedź dostawcy płatności albo trwały zapis zdarzenia, nie przypadkowy odczyt z panelu CRM. Dopiero po potwierdzeniu można uruchomić kolejne skutki uboczne.

Projektując workflow, zdefiniuj granicę czasową i stan końcowy. Zapisz, ile maksymalnie czekasz na propagację, które zdarzenie jest autorytatywne i co robisz, gdy synchronizacja nie nadejdzie. Timeout po kilku sekundach nie dowodzi utraty danych. Może uruchomić ponowienie lub kontrolę, ale nie automatyczne utworzenie nowej sprawy. Dla krytycznych przypadków użyj kolejki, rejestru zdarzeń i alertu. Architektura sterowana zdarzeniami pomaga oddzielić przyjęcie polecenia od późniejszego przetworzenia, lecz wymaga obserwowalności każdego etapu.

Ważne jest też rozróżnienie spójności danych od kolejności zdarzeń. Webhook „kontakt zaktualizowany” może dotrzeć przed „kontakt utworzony”, a dwa systemy mogą przetwarzać wiadomości w różnym tempie. Nie zakładaj, że kolejność dostarczenia jest kolejnością biznesową. Przechowuj czas zdarzenia, wersję albo numer sekwencyjny, jeśli dostawca go daje. Gdy przyjdzie starsza aktualizacja, nie powinna nadpisać nowszego stanu. Kontrakt danych powinien określać identyfikator, znaczenie statusów i zachowanie przy duplikacie lub wiadomości poza kolejnością.

Najczęstszy antywzorzec to pętla sprawdzająca co sekundę, która po krótkim czasie tworzy kolejny rekord albo wysyła drugą wiadomość. Drugi to ukrywanie procesu asynchronicznego pod obietnicą „gotowe natychmiast”. Lepsza zasada brzmi: akcję przyjmij raz, pokaż jej identyfikator, przetwarzaj asynchronicznie i aktualizuj stan w jednym miejscu. Jeśli potrzebujesz odczytu natychmiast po zapisie, wybierz rozwiązanie oferujące taką gwarancję lub zaprojektuj lokalny stan potwierdzenia. Nie próbuj naprawiać architektury samymi promptami do AI.

Zacznij od jednego przepływu, w którym występuje kilka narzędzi, na przykład formularz, CRM i sekwencja e-mailowa. Narysuj zdarzenie początkowe, właściciela źródła prawdy, identyfikator sprawy, stany przejściowe i punkt końcowy. Następnie zasymuluj opóźniony webhook oraz dwukrotne dostarczenie tej samej wiadomości. Jeżeli system tworzy dwa kontakty, nie umie pokazać stanu „w toku” albo nie potrafi odzyskać sprawy po awarii, nie jest gotowy na automatyczne skalowanie. Spójność ostateczna jest użyteczna tylko wtedy, gdy jej przejściowy charakter jest świadomie obsłużony.