Моделі узгодженості

Узгодженість описує, які значення і в якому порядку бачать читачі при конкурентних змінах. Правильний вибір моделі - це баланс між строгістю інваріантів, латентністю, доступністю і вартістю (PACELC). Нижче - практичний довідник з моделей та їх застосування.

1) «Строгі» моделі

Linearizable (лінійризованість, Strong)

Поведінка як ніби всі операції виконувалися миттєво в деякому єдиному порядку, поважає реальний час.
Плюси: проста ментальна модель, безпечна для грошей і унікальностей.
Мінуси: кворуми/лідер → зростання p95/p99, особливо міжрегіонально.
Юзкейси: баланси, інвентар з жорсткими лімітами, унікальні імена/ключі.

Sequential consistency

Всі потоки бачать один і той же порядок операцій, але не обов'язковий реал-тайм порядок. Трохи слабкіше linearizable, рідко експонується безпосередньо в продуктах.

Serializable (транзакційна серіалізованість)

Еквівалентно деякому послідовному порядку транзакцій (а не окремих операцій).
Плюси: коректність складних інваріантів на рівні запитів/таблиць.
Мінуси: дорожче (блокування/версіонування/валідація конфліктів).
Юзкейси: складні фіноперації, консистентні перерахунки, інвентар.

Snapshot Isolation (SI)

Кожна транзакція читає незмінний знімок у часі; записи конфліктують по «однакових рядках», але можливий write skew.
Плюси: швидкі читання без блокувань, стабільні звіти.
Мінуси: не серіалізуемо, пастка write skew (приклад: чергові лікарі).
Юзкейси: аналітика, звіти, більшість CRUD без жорстких інваріантів.

2) Per-session і причинні гарантії

Read-Your-Writes (RYW)

Клієнт після свого запису завжди бачить її в наступних читаннях.
Плюси: хороший UX (форма → підтвердження).
Мінуси: локальна гарантія, не глобальна.

Monotonic Reads / Writes

Читання не «відкочуються» назад; записи одного клієнта застосовуються в тому ж порядку, що і відправлялися.

Causal Consistency (причинна)

Якщо операція залежить від іншої (A → B), всі бачать A перед B.
Плюси: інтуїтивно для соц-фідів, коментарів.
Мінуси: складніше маршрутизація і мітки причинності (векторний годинник).
Юзкейси: комунікації, спільне редагування, стрічки подій.

3) Слабкі і гібридні моделі

Bounded Staleness

Читання можуть відставати не більше Δ t або N версій.
Плюси: передбачуваний UX, хороший компроміс міжрегіонально.
Мінуси: не захищає від конфліктів записи.

Eventual Consistency

З часом всі копії сходяться; порядок і затримка не гарантовані.
Плюси: мінімальна латентність/вартість, висока доступність (AP).
Мінуси: потрібен явний merge (CRDT/правила домену).
Юзкейси: кеші, фіди, метрики, лайки, нен critical довідники.

4) Типові аномалії і що вони означають

Dirty Read: читання незакомічених даних.
Non-repeatable Read: одне і те ж читання всередині транзакції дає різні значення.
Phantom: при повторному запиті з'являється/зникає рядок, що підходить під предикат.
Write Skew (при SI): дві транзакції читають інваріант, що перетинається, і записують різні рядки, порушуючи умову «в сумі має бути ≥ 1».
Lost Update: запис «затирає» зміни конкурента.

5) Кворуми та рівні читання/запису

Багато сховищ дозволяють задавати рівні'R '/' W'( число реплік для читання/запису).

Кворум (R + W> N) дає «перетин» і сильні гарантії читань останнього запису.
W = 1, R = 1 → низька затримка, але можливі старі дані.
Тюнінг: критичним операціям - високий'W'( або лідер), іншим - низький'R'для швидкості.
Read-repair/Hinted handoff допомагають добирати узгодженість у тлі.

6) Годинник і порядок: як ми «розуміємо» причинність

Lamport clocks: частковий порядок подій.
Vector clocks: фіксують причинність, дозволяють детектувати конфлікти.
Hybrid/TrueTime-підходи: обмежують розкид годинників в кластері для впорядкування транзакцій і bound-staleness.
Версіонування: `version/ts + actor` для merge; в CRDT - замкнуті напівгрупи (комутативність/ідемпотентність).

7) CRDT і доменний merge

CRDT (конвергентні/репліковані типи даних) гарантують сходження без координації: G-Counter, OR-Set, LWW-Register, Map, текстові OT/WOOT-варіанти.
Коли корисно: лайки, безлічі тегів, кошики, документи.
Обмеження: придумати коректну семантику «злиття» для конкретної доменної сутності.

8) Зв'язок з CAP/PACELC

Строгі моделі (Linearizable/Serializable) в мульти-регіоні → CP зі зростанням латентності (PACELC: вибираємо C і платимо L).
Слабкі/гібридні моделі → AP і/або низька L, але потрібен merge/конфлікт-резолв.
Гібрид: CP-ядро для інваріантів + AP-проекції/кеші для читань.

9) Вибір моделі: чек-лист

1. Інваріанти: що не можна порушувати? (унікальність, баланс, ліміти).
2. Регіональність: де виконуються записи/читання? (локально/глобально).
3. SLO за латентністю: p95/p99 для критичних шляхів?
4. Ціна координації: готові платити міжрегіональними кворумами?
5. Конфлікти: є детермінований merge або потрібен координатор?
6. UX-очікування: RYW/monotonic/causal для клієнта важливі?
7. Спостережуваність: чим міряєте лаг/конфліктність/ступінь застарівання?
8. Фолбеки: що відбувається при поділі мережі (P)? read-only/локальний запис/черги?

10) Швидкі рецепти

Платіж/баланс: Linearizable/Serializable, лідер + кворум, короткі таймаути; читання RYW.
Профілі/фід: Causal/Bounded staleness + кэш; CRDT для лайків/лічильників; RYW для автора.
Пошук/аналітика: SI/Read Committed, асинхронні проекції, eventual для індексів.
Глобальний SaaS: Geo-partitioning; «домашні записи» - CP, звіти/каталоги - AP.
Спільне редагування: причинна/eventual + CRDT/OT; збереження «історії».

11) Спостережуваність узгодженості

Lag метрики: `replication_lag`, `staleness_age_ms` (p50/p95/p99).
Конфліктність: частка конфліктів, середній час вирішення.
Кворуми: успішність'R/W'кворумів, таймаути міжрегіональних шляхів.
Клієнтські гарантії: RYW/monotonic - трейс-мітки по сесіях.

12) Типові помилки

Вимагати Strong «скрізь» без бізнес-підстави → вибух латентності і вартості.
Dual-write в різні регіони без саг/CRDT → фантоми і втрата інваріантів.
Ігнорувати RYW/монтонічність в UX → «пропажа» щойно відправлених даних.
Не відстежувати застарівання кешів/проекцій → «вічні» розбіжності.
Непродуманий merge → несподівані втрати/дублі значень.

13) Міні-еталон архітектури

Write-core (CP): лідер, кворумні записи, SLO і таймаути, журнали.
Read-plane (AP): матеріалізовані представлення, TTL-кеші, read-repair.
Клієнт: sticky-session/сесійні гарантії (RYW/monotonic), мітки версії.
Конфлікт-рушій: CRDT/доменні правила, черга ручного врегулювання.
Моніторинг: лаги, конфлікти, частки застарілих читань.

Висновок

Модель узгодженості - це інженерний контракт між даними, затримкою і доступністю. Починайте з інваріантів і SLO, вибирайте строго там, де потрібно, і слабкіше там, де можна, не забуваючи про клієнтські гарантії, кворуми, годинник і спостережуваність. Грамотна комбінація моделей дає масштаб, передбачуваність і стійкість - без жертвування бізнес-правдою і користувальницькою довірою.