Мы привыкли считать, что после изменения данные везде должны стать правильными мгновенно. В одной базе это естественное ожидание. В распределённой системе оно может потребовать сложной координации между сервисами и регионами.
Eventual consistency допускает другое: разные части системы могут короткое время видеть разные состояния, но затем сходятся к одному результату.
Какую проблему мы решаем
Строгая синхронизация всех компонентов увеличивает связанность. Один медленный или недоступный участник может задержать весь процесс.
Если часть данных можно обновить чуть позже, системы получают больше независимости.
Что получает бизнес
Бизнес получает возможность масштабировать процессы и команды без обязательной синхронной координации каждой операции.
Заказы, уведомления, поисковые индексы, отчёты и рекомендации не всегда обязаны обновляться в одну миллисекунду. Если допустимая задержка определена явно, продукт может быть дешевле и устойчивее.
Но главное — различать данные. Остаток денег на счёте и счётчик просмотров имеют разную цену ошибки.
Что получает команда
Команды могут обновлять свои данные независимо и обрабатывать события асинхронно. Это уменьшает количество синхронных зависимостей.
Взамен приходится проектировать повторную обработку, порядок событий, дедупликацию и способы исправления расхождений.
Что получает клиент
Клиент получает более доступный продукт, но иногда видит задержку: заказ создан, а в истории появляется через несколько секунд; документ обновлён, а поиск ещё показывает старую версию.
Если такие состояния возможны, интерфейс должен объяснять их, а не выдавать временную несогласованность за ошибку.
Чем мы за это платим
Цена — сложнее мыслить о данных. Появляются промежуточные состояния, которые нужно поддерживать, тестировать и объяснять.
Ошибочно применять eventual consistency к операциям, где даже краткое расхождение создаёт финансовый, юридический или репутационный риск.
Когда eventual consistency не нужна
Если операция локальна и легко выполняется в одной транзакции, строгая консистентность проще. Не нужно распределять проблему раньше времени.
Что стоит спросить перед решением
- Какую задержку бизнес реально готов принять?
- Какие данные должны быть правильными мгновенно?
- Что увидит клиент в промежуточном состоянии?
- Как система исправит потерянное или повторное событие?
В итоге
Eventual consistency — это не разрешение иметь неправильные данные. Это договор о том, где небольшая задержка дешевле и безопаснее постоянной глобальной синхронизации.