Cześć!

Pracuję aktualnie nad dwudniowym szkoleniem z Event-Driven Architecture. Niby już miałem przygotowane slajdy, ale oczywiście stwierdziłem, że “doszlifuję” slajdy. I cyk! Weekend zarwany… Pod tym kątem przerobiłem klasyczny obrazek znany wśród programistów jako przykład Eventual Consistency.

Zauważyłem, że wiele osób gdy mówi Eventual Consistency, to ma na myśli, że “a tak, wydarzy się z poślizgiem”. W domyśle: wykona się tak jak trzeba, tylko kiedy się zakończy? Nie wiadomo. Kluczowym aspektem tutaj jest właśnie ten “jak trzeba”. Co to dokładnie znaczy?

Czy znaczy, że operacje będą przetworzone w takiej kolejności jak je zrobił użytkownik? Czy oznacza, że ani przez moment stan będzie błędny?

Otóż, Eventual Consistency nie daje takich gwarancji. Eventual Consistency to bardzo pojemne stwierdzenie. W skrócie wiemy, że jeśli damy chwilę czasu, to stan powinien się ustabilizować i być poprawny. Wszystkie zaakceptowane operacje powinny zostać zaaplikowane. I tyle. Eventual Consistency nie daje nam gwarancji kolejności przetworzenia operacji. Nie mówi też nam ile razy operacja będzie zaaplikowana.

O gwarancjach kolejności zdarzeń mówi nam Causal Consistency. Causality to z angielskiego “przyczynowość”. Causal Consistency gwarantuje nam, że powiązane ze sobą przyczynowo-skótkowo operacje będą zaaplikowane w takiej kolejności jakiej zaszły.

To jest Causal Consistency:

To jest Eventual Consistency:

Causal Consistency nie musi nam dawać gwarancji zachowania kolejności wszystkich operacji, które zaszły w systemie. To też zawsze trzeba zweryfikować.

To nie jest takie Strong Consistency, tylko z lekkim opóźnieniem. To znaczy może, być ale nie musi. Wszystko zależy od tego jakie gwarancje daje nam konkretne rozwiązanie. Na przykład Kafka daje gwarancje kolejności przetwarzania zdarzeń. Jednak nie daje nam ich globalnie, co więcej nie daje nam nawet na poziomie topicu (logicznego zgrupowania zdarzeń). Daje nam na poziomie partycji (fizycznej sekwencji zdarzeń). Dodatkowo może się zachować różnie w zależności od ustawień dotyczących powtarzania w przypadku błędu itd. Jeśli byśmy chcieli mieć w Kafce globalną kolejność zdarzeń to musielibyśmy mieć jeden topic, który ma jedną partycję. Jeśli tego nie doczytamy, to możemy się przekonać o tym za późno - na własnej skórze.

Dlatego jak zawsze apeluję o sięganie do źródeł i sprawdzanie jakie gwarancje daje nam nasze narzędzie. Tematy związane ze spójnością danych, kolejnością itd. są szczególnie kluczowe przy wyborze bazy danych, systemu do messagingu. Mogą one bardzo wpłynąć na architekturę naszego rozwiązania.

Co o tym sądzisz?

Pozdrawiam

Oskar

p.s. zachęcam do lektury mojego ostatniego artykułu o tym “Typowaniu strukturalnym w TypeScript”: https://event-driven.io/pl/structural_typing_in_type_script/.

oraz nowego Architecture Weekly: https://github.com/oskardudycz/ArchitectureWeekly#14th-june-2021.

Przerobiony obrazek pochodzi z komiksu Mister invincible: http://www.magnetic-press.com/mr-invincible/