Переходим к следующему мифу.

⚓️ Когда eventual consistency — это не про данные, а про бизнес-процессы

Моя "любимая" согласованность... в кавычках, потому что, мне кажется, я на своих докладах всем вынесла мозг с ней. Рассмотрим очередную ее грань...

Асинхронность часто связана с eventual consistency: данные рано или поздно синхронизируются. Это звучит безобидно — пока не проявляется в пользовательских сценариях...

Пример: заказ создан, но платёж «где-то едет»

Пусть пользователь оформляет заказ. Фронтенд получает успешный ответ: «Заказ создан». Через секунду он открывает историю заказов — а там заказа нет, потому что поток обработки платежей задержался, и сервис заказа пока не обновил статус.
Что думает пользователь?
«Сайт сломался, надо оформлять заново». Даже если бизнес-процесс формально корректен, пользователь все равно идет оформлять повторно.

Вот что стоит помнить:
🎲 Eventual consistency — это не только про репликацию данных.
Это про рассинхронизацию реальности и того, что видит пользователь!! Поэтому асинхронность вынуждает продумывать UX иначе.

🎲 Нужно объяснять пользователю, что происходит: «Платеж обрабатывается…». А это означает изменения интерфейса, API, состояния в БД, SLA на задержки.

🎲 Асинхронная архитектура = асинхронный бизнес.

🎲 Процессы меняются: появляется потребность в сагах, компенсационных транзакциях, промежуточных состояниях.


Иными словами, внедряя асинхронность, вы меняете не только технологию, но и то, как бизнес работает с реальностью.
Казалось бы, очевидное утверждение. Но оно не всегда вспоминается при проектировании. Поэтому призываю вас ❗️ сделать это утверждение своей парадигмой, когда вы проектируете асинхронные процессы.