Eventual Consistency на практике

Eventual consistency (EC) — модель, в которой копии данных могут временно расходиться, но со временем сходятся без глобальной координации. Это ключ к высокой доступности (AP по CAP) и низкой латентности (PACELC), если правильно определить инварианты, правила мерджа и клиентские гарантии.

1) Когда выбирать EC (и когда — нет)

• Фиды, профили, лайки/счетчики, каталоги/поиск, кэшированные представления.
• Глобальные системы с локальными записями и мягкими инвариантами.
• Проекции (CQRS), где источник истины — строгое ядро, а чтения — асинхронны.

• Жесткие инварианты: деньги, единственность, лимиты, инвентарь «не уйти в минус». Там — CP/сильнее EC, саги/TCC.

2) Дизайн данных под EC: конфликты и их разрешение

Принцип: каждая запись несет метаданные версий и детерминированную функцию слияния.

Метки времени/версионирование: `version`, `ts`, `actor`.
Векторные часы: фиксируют причинность, позволяют понять «конфликтующие параллели».

• LWW (Last-Write-Wins): просто и быстро, но может потерять «смысл».
• CRDT: коммутативные/идемпотентные структуры, гарантируют схождение.
• Доменный merge: бизнес-функция (например, объединить списки без дублей, суммировать счетчики, «самый новый email + объединение тегов»).

• Счетчики → G-Counter/PN-Counter.
• Множества → OR-Set (удаления без «залипания»).
• Регистры → LWW-Register (с осторожностью к «потерям»).
• Карты/документы → Map of CRDTs.
• Совместное редактирование → текстовые CRDT/OT.

3) Репликация и анти-энтропия

Gossip/anti-entropy: периодический обмен состояниями/хэшами между узлами.
Hinted handoff: временное «депонирование» записи для недоступного узла.
Read repair: при чтении обнаружили рассогласование — подтянули свежие версии.
Пакеты изменений (deltas): гоняем дельты, а не полные снимки.
Кворумы R/W: настраиваем `R`, `W`, `N` под компромисс скорости и свежести (например, `R+W>N` ближе к strong на «последней записи»).

4) Клиентские гарантии поверх EC

Read-Your-Writes (RYW): автор после своей записи видит ее (sticky-session/маркировка версии).
Monotonic Reads: не «откатываем» клиента на более старое значение (храним watermark последней версии).
Causal Consistency: сохраняем причинность в пределах сессии/потока действий (векторные метки в заголовках/токенах).
Bounded Staleness: гарантия «не старше Δt / N версий» для UX-критичных экранов.

5) UX-паттерны для EC

Оптимистические апдейты: моментально отражаем действие, помечая «синхронизацию».
Маркировка свежести: бейдж «обновлено X сек назад», кнопка «Обновить».
Конфликт-UI: для редких коллизий — «показать обе версии и выбрать/объединить».
Скелетон/placeholder + soft refresh: не блокировать UI ожиданием глобальных кворумов.

6) Архитектурные шаблоны

6.1 CQRS + проекции

Write-ядро (CP): строгие инварианты.
Read-плоскость (EC): асинхронные проекции, индексы, кэши; лаг допустим.

6.2 Мульти-регион AP

Записи локально быстро, репликация асинхронно.
Geo-partitioning: данные «живут» ближе к пользователю; кросс-регион — агрегаты.
CRDT/merge-функции снимают боль конфликтов.

6.3 Кворумная настройка

yaml consistency:
replicas: 3 # N write_quorum: 2 # W read_quorum: 2 # R => R + W> N, closer to freshness on "last record"
read_repair: true hinted_handoff: true

7) Политики версиирования и merge (пример)

yaml entity: "profile"
versioning:
clock: "vector"    # или "hybrid_time"
fields:
name:   { merge: "lww" }
emails:  { merge: "set_union" }   # OR-Set tags:   { merge: "or_set" }
likes:   { merge: "pn_counter" }
conflict_ui:
enabled: true show_diff_for: ["name"]
auto_merge_for: ["emails","tags","likes"]

8) Наблюдаемость EC: что мерить

Staleness Age (p50/p95/p99): `now − data_version_ts` или «число версий отставания».
Replication Lag: задержка доставки между регионами/узлами.
Conflict Rate: доля параллельных апдейтов, распределение по типам.
Read-Repair Rate/Latency: как часто и как быстро «лечим» при чтении.
Convergence Time: время до схождения после всплеска записей/отказа узла.
Семантические SLO: «95% профилей не старше 2с», «99% фида сходится < 10с».

9) Runbook’и и инциденты

1. Рост lag межрегионально: снизить `write fan-out`, включить агрессивный read-repair, троттлить тяжелые писатели.

2. Всплеск конфликтов: временно включить более «строгое» правило (например, causal/RYW), ограничить конкурентные апдейты на горячих ключах.

3. Отставание проекций: приоритизировать очереди репликации, временно урезать частоту не-критичных апдейтов.

4. Данные «залипли» у части узлов: форс-анти-энтропия, ребаланс партиций, аудит hinted handoff.

5. Ручной разбор: выгрузка конфликтных ключей, инструмент «merge-preview», батчевый фикс.

10) Тестирование EC

Jepsen-подобные тесты: разделения сети, clock-skew, повторные записи.
Property-based: инварианты merge-функций (коммутативность, идемпотентность, ассоциативность).
Fuzz-конфликты: параллельные апдейты на один ключ с вариативным порядком доставки.
Нагрузочные «пилы»: чередование бурстов/затиший для оценки convergence time.
UX-симуляции: видимость RYW/monotonic в типичных сценариях.

11) Мульти-тенант и планы

Теги `tenant_id/plan/region` в событиях/записях.
Fairness: лимиты на репликацию/repair per tenant, чтобы «шумный» клиент не увеличивал общий staleness.
Residency: данные и их реплики в пределах юрисдикции; кросс-региональные представления только агрегаты.

12) Типичные ошибки

LWW «для всего». Теряет смысловые параллельные изменения; используйте CRDT/доменные merge.
Нет клиентских гарантий. Пользователь «не видит» собственную запись → потеря доверия.
Отсутствие наблюдаемости устаревания. Нет метрик staleness/lag → «скрытая деградация».
Dual-write в разные системы без merge. Фантомы и расхождения бесконечно.
Глобальный порядок любой ценой. Лишние кворумы убивают p95, а бизнесу достаточно локального порядка.

13) Быстрые рецепты

Фид/лента: EC + causal/RYW для автора, CRDT для реакций, staleness p95 ≤ 2–5с.
Профили/настройки: bounded staleness (≤1–2с), RYW, доменный merge (union множеств).
Глобальный каталог: geo-partition, асинхронная репликация, read-repair по запросу, конфликты через OR-Set.
Метрики/счетчики: PN-Counter, консолидация в фоне; отображение «приблизительных» значений с пометкой.

14) Мини-эталон (словесная схема)

Write-edge: локальная запись с версией (`vector/hybrid`), журнал событий.
Replication: очереди + gossip/anti-entropy, hinted handoff.
Storage: партиционирование по ключу, CRDT/мердж-функции на уровне записи.
Read-plane: кэши с read-repair, RYW/monotonic токены, bounded staleness для критичных экранов.
Observability: лаги/устаревание/конфликты, алерты на превышение SLO стейлнесса.

15) Чек-лист перед продом

• Четко описаны инварианты и где допускается EC.
• Выбраны версионирование (vector/hybrid) и детерминированные функции merge/CRDT.
• Реализованы клиентские гарантии (RYW/monotonic/causal) для критичных UX.
• Настроены репликация, read-repair, hinted handoff; кворумы R/W документированы.
• Метрики staleness/lag/convergence и алерты по порогам p95/p99.
• Runbook’и на рост конфликтов/лагов; безопасные инструменты ручного merge.
• Тесты на сетевые разделения, параллельные апдейты и свойство сходимости.
• Мульти-тенантные лимиты и residency-политики учтены.
• UX-индикаторы свежести и fallback-поведение согласованы с продуктом.

Заключение

Eventual consistency — не «компромисс ради компромисса», а инструмент масштабируемости и доступности. Если вы формализуете инварианты, выберете корректные merge-функции (желательно CRDT там, где это уместно), дадите клиентские гарантии и будете измерять стейлнесс и время схождения, система будет быстрой, устойчивой и честной — и для пользователей, и для бизнеса.