Темна сторона транзакцій. Частина 1: ACID, BASE і чому isolation level — це не просто налаштування

CREATE TABLE accounts (
 id BIGINT PRIMARY KEY,
 balance NUMERIC NOT NULL CHECK (balance >= 0)
);

BASE: не «поганий ACID», а інша модель компромісів

Після ACID легко зробити неправильний висновок:
«ACID — це правильно. BASE — це коли база не вміє нормально працювати з даними.»

Але це занадто спрощене бачення.

BASE — це не «зламаний ACID».
BASE — це інша модель компромісів.

Якщо ACID намагається дати сильні гарантії для транзакцій, то BASE частіше зʼявляється там, де система ставить на перше місце доступність, масштабування, latency і роботу в розподіленому середовищі.

BASE зазвичай розшифровують як:

• Basically Available;
• Soft state;
• Eventually consistent.

Звучить трохи абстрактно, тому розберемо по-людськи.

Basically Available: система намагається відповідати навіть тоді, коли не все ідеально

У класичній ACID-транзакції ми часто очікуємо чітку відповідь:

Або зміна успішно застосована, або ні.

У BASE-системах підхід може бути іншим.

Система може прийняти запит, записати його локально, поставити подію в чергу, оновити частину реплік, а решту підтягнути пізніше.

Головна ідея:

Краще дати користувачу доступну систему з тимчасово неповною консистентністю, ніж повністю відмовити в роботі.

Наприклад, уявімо соціальну мережу.

Користувач лайкає пост.
Один сервіс уже записав лайк.
Інший ще не оновив лічильник.
Третій ще не перебудував рекомендації.
Четвертий ще не оновив feed.
Кілька секунд різні частини системи можуть показувати трохи різну картину.

Для лайків це зазвичай нормально.
Для банківського балансу — ні.
І в цьому вся суть.

BASE не каже: «Консистентність не потрібна».

BASE каже: «Не кожна операція в системі потребує однаково сильної консистентності».

Soft state: стан системи може змінюватися не тільки через прямий запит користувача

У простій CRUD-моделі ми часто думаємо так:

користувач зробив запит → база змінила стан.

Але в розподілених системах стан може змінюватися асинхронно.

Наприклад:

• прийшла подія з черги;
• оновилася репліка;
• пройшов background job;
• кеш інваліднувся;
• projection перебудувався;
• аналітичний агрегат дорахував нові значення;
• search index підтягнув останні зміни.

Тобто система може бути в «мʼякому» стані.
Не в сенсі «хаотичному».

А в сенсі: її різні частини можуть тимчасово не збігатися, але поступово сходяться до правильного результату.

Наприклад, користувач оновив імʼя профілю.
У головній базі імʼя вже нове.
У кеші ще старе.
У search index ще старе.
В email template вже нове.
У billing-системі ще старе.
Це не обовʼязково катастрофа.

Якщо така тимчасова розбіжність допустима для бізнесу — BASE-підхід може бути нормальним.

Але якщо мова про списання грошей, доступ до акаунту, compliance check або унікальність критичного запису — такий підхід може бути небезпечним.

Eventually Consistent: дані стануть узгодженими, але не обовʼязково одразу

Eventually consistent означає:

Якщо нових змін не буде, система з часом прийде до узгодженого стану.

Ключові слова тут — з часом.

Не обовʼязково зараз.
Не обовʼязково в межах поточного запиту.
Не обовʼязково в усіх репліках одночасно.

Наприклад:

користувач створив пост;
пост одразу зʼявився в його профілі;
у feed підписників він зʼявиться через кілька секунд;
у пошуку — через хвилину;
в аналітиці — після наступної обробки batch job.

Це може бути абсолютно прийнятно.

Але якщо користувач щойно оплатив підписку, а система ще 10 хвилин вважає його free-userʼом — це вже може бути проблемою.

Тому питання не в тому, чи eventual consistency «добра» або «погана».

Питання в іншому:

Де саме у вашій системі допустима затримка консистентності, а де потрібна сильна гарантія одразу?

ACID і BASE — це не SQL проти NoSQL

Ще одна популярна помилка:

SQL-бази — це ACID.

NoSQL-бази — це BASE.

У реальності все складніше.
PostgreSQL, MySQL InnoDB, SQL Server і Oracle справді мають сильну транзакційну модель.

Але це не означає, що кожна операція у вашій архітектурі автоматично ACID.

Якщо ви оновили рядок у PostgreSQL, потім відправили повідомлення в Kafka, потім викликали Stripe, потім оновили Redis-кеш — це вже не одна проста ACID-транзакція.

З іншого боку, деякі NoSQL-бази також мають транзакційні механізми.
MongoDB підтримує multi-document transactions.
Redis має MULTI/EXEC і WATCH.
Cassandra має lightweight transactions для окремих сценаріїв compare-and-set.
Neo4j, як graph database, теж підтримує ACID-транзакції, але в зовсім іншій моделі даних.

Неправильно думати категоріями: «SQL — серйозно, NoSQL — приблизно.»

Правильніше ставити конкретні питання:

• яка саме операція виконується?
• вона змінює один рядок, один документ, одну partition чи багато різних сутностей?
• чи є паралельні записи?
• чи є бізнес-інваріант?
• що буде при retry?
• що буде при network partition?
• чи потрібна миттєва консистентність?
• чи достатньо eventual consistency?
• чи можна компенсувати помилку пізніше?
• чи можна зробити операцію idempotent?

Тільки після цього можна чесно вибирати модель.

Приклад: де BASE підходить добре

Уявімо систему рекомендацій для FinTech-додатку.

Користувач виконав кілька дій:

• відкрив savings account;
• кілька разів переглянув investment products;
• поповнив баланс;
• відхилив кредитну пропозицію.

На основі цих подій система має оновити рекомендації.
Чи потрібно робити це в одній синхронній ACID-транзакції разом з основною операцією?
Скоріше за все, ні.

Можна записати основну подію надійно, а рекомендації перебудувати асинхронно.

Якщо нова рекомендація зʼявиться через 10 секунд або навіть через кілька хвилин — це не зламає фінансову цілісність системи.

Тут BASE-підхід нормальний.

Ба більше, він може бути кращим.
Бо ми не блокуємо основну операцію через допоміжну логіку.
Не змушуємо користувача чекати, поки оновиться аналітика.
Не створюємо зайву звʼязаність між transactional core і recommendation engine.

Приклад: де BASE може бути небезпечним

А тепер інший сценарій.

Користувач хоче вивести гроші.

Система має перевірити:

• чи достатньо балансу;
• чи не перевищено ліміт;
• чи пройдено compliance check;
• чи немає hold на акаунті;
• чи не виконується вже інший payout.

Тут eventual consistency може бути небезпечною.

Якщо один сервіс бачить старий баланс, інший ще не знає про hold, а третій ще не отримав результат compliance check — система може дозволити операцію, яку не мала дозволити.

У таких місцях зазвичай потрібна сильніша модель:

• транзакція;
• constraint;
• lock;
• idempotency key;
• optimistic або pessimistic locking;
• retry logic;
• чітка межа consistency boundary.

Тобто BASE не є проблемою сам по собі.

Проблема починається тоді, коли BASE-підхід випадково застосовують там, де бізнес очікує ACID-гарантій.

Найважливіше питання: де ваша consistency boundary?

У будь-якій складній системі треба розуміти, де проходить межа консистентності.

Consistency boundary — це частина системи, всередині якої дані мають залишатися узгодженими одразу.

Наприклад, для банківського переказу consistency boundary може включати:

• balance;
• ledger entries;
• transaction status;
• idempotency key;
• audit trail.

Ці речі мають змінюватися як єдина логічна операція або через дуже чітко контрольований workflow.

А от recommendation model, email notification, analytics event, search projection чи dashboard metric можуть оновитися пізніше.

Їх не обовʼязково тягнути в ту саму транзакцію.

Це важлива архітектурна думка:

Не все в системі має бути strongly consistent, але ви повинні точно знати, що саме має бути strongly consistent.

Якщо цього не визначити, система поступово перетворюється на набір випадкових компромісів.
Десь ми блокуємо занадто багато.
Десь дозволяємо занадто багато паралельності.
Десь довіряємо кешу, де не можна.
Десь робимо distributed workflow без idempotency.
Десь очікуємо від бази гарантій, яких вона не давала.

Коротко

BASE — це не «поганий ACID».

Це інша модель компромісів:

• Basically Available — система намагається залишатися доступною;
• Soft state — різні частини системи можуть тимчасово бачити різний стан;
• Eventually consistent — з часом дані мають зійтися до узгодженого стану.

BASE добре підходить для:

• кешів;
• рекомендацій;
• лічильників;
• feedʼів;
• аналітики;
• search index;
• projections;
• не критичних read models.

BASE може бути небезпечним для:

• балансів;
• платежів;
• payout;
• compliance-рішень;
• унікальних бізнес-обмежень;
• доступів і permissions;
• операцій, де помилку складно компенсувати.

Головне питання не «ACID чи BASE?».

Головне питання:

Які гарантії потрібні саме цій операції?

І щоб відповісти на це питання, треба глибше розібрати isolation.

Бо саме isolation найчастіше визначає, що станеться, коли кілька транзакцій одночасно працюють з одними й тими самими даними.

Рівні ізоляції: чому класична таблиця не розповідає всю правду

Коли розробники вперше вивчають isolation levels, вони зазвичай бачать приблизно таку таблицю:

Isolation level	Dirty read	Non-repeatable read	Phantom read
Read Uncommitted	possible	possible	possible
Read Committed	prevented	possible	possible
Repeatable Read	prevented	prevented	possible
Serializable	prevented	prevented	prevented

Ця таблиця корисна.
Але вона небезпечна, якщо сприймати її як повну картину.
Бо в реальних базах даних все складніше.

По-перше, різні бази можуть по-різному реалізовувати рівні з однаковими назвами.
Repeatable Read у PostgreSQL — це не те саме, що Repeatable Read у MySQL InnoDB.
Read Committed у PostgreSQL — не те саме, що Read Committed у SQL Server з увімкненим READ_COMMITTED_SNAPSHOT.
Serializable у PostgreSQL — це не просто «поставити locks на все», а Serializable Snapshot Isolation.

По-друге, класична таблиця говорить лише про три явища:

• dirty read;
• non-repeatable read;
• phantom read.

Але в реальних системах нас цікавлять також:

• lost update;
• write skew;
• read skew;
• serialization anomalies;
• lock contention;
• deadlocks;
• retry behavior;
• visibility rules;
• MVCC snapshots;
• predicate locks;
• gap locks;
• next-key locks.

По-третє, сама назва isolation level не відповідає на питання:

Чи безпечно мені реалізувати конкретний бізнес-сценарій саме так?

Вона лише задає приблизну модель того, що транзакція може бачити.
Тому ми підемо не від таблиці до життя, а навпаки.
Спочатку розберемо проблеми, які виникають при паралельних транзакціях.
Потім подивимось, які isolation levels їх дозволяють або забороняють.
А вже після цього порівняємо, як різні бази даних реалізують ці гарантії.

Dirty read: читання даних, яких може ніколи не існувати

Dirty read — це ситуація, коли одна транзакція читає зміни іншої транзакції, які ще не були закомічені.

Уявімо:

Транзакція B побачила баланс 0.
Але транзакція A зробила ROLLBACK.

Тобто з точки зору фінального стану бази балансу 0 ніколи не існувало.
Якщо B прийняла бізнес-рішення на основі цього значення, вона використала «брудні» дані.
Звідси і назва — dirty read.

У нормальних transactional systems dirty read майже ніколи не є тим, чого ви хочете.
Для фінансових операцій це очевидно небезпечно.

Але навіть у звичайному CRUD це може створити дивні баги:

• користувач бачить статус, який потім зникає;
• сервіс відправляє notification про зміну, яку відкотили;
• background job бере в роботу запис, який фактично не був створений;
• аналітика рахує подію, якої не сталося.

Саме тому багато баз даних або взагалі не дозволяють dirty reads, або роблять Read Uncommitted фактично сильнішим, ніж звучить з назви.

Наприклад, PostgreSQL формально приймає рівень Read Uncommitted, але поводиться як Read Committed.

Тобто навіть якщо ви попросите найслабший рівень, PostgreSQL все одно не дасть вам читати незакомічені зміни інших транзакцій.

Non-repeatable read: один і той самий рядок змінився всередині транзакції

Non-repeatable read виникає тоді, коли транзакція двічі читає один і той самий рядок і отримує різні результати, бо між читаннями інша транзакція закомітила зміну.

Наприклад:

Транзакція A в межах однієї транзакції побачила два різні значення одного й того самого рядка.
Це може бути нормально.
А може бути дуже погано.

Якщо ви просто показуєте користувачу актуальні дані — можливо, все окей.
Але якщо ви робите розрахунок, який має базуватися на стабільному стані, це вже ризик.

Наприклад:

• перший запит читає balance;
• другий читає pending operations;
• третій знову читає balance;
• application збирає з цього фінальне рішення.

Якщо дані між читаннями змінились, ви можете прийняти рішення на основі суміші різних моментів часу.
Це особливо неприємно для звітів, фінансових розрахунків, reconciliation, risk scoring і складних workflow.
Read Committed зазвичай дозволяє таку поведінку.

Бо його базова гарантія проста:

Кожен запит бачить тільки закомічені дані, але різні запити всередині однієї транзакції можуть бачити різні закомічені стани.

Тобто Read Committed захищає від dirty read.
Але не гарантує, що snapshot буде стабільним протягом усієї транзакції.

Phantom read: змінився не рядок, а результат умови

Phantom read — це ситуація, коли транзакція двічі виконує один і той самий запит за умовою, але вдруге бачить нові рядки, які зʼявились через паралельну транзакцію.

Наприклад:

Транзакція A не побачила зміну конкретного рядка.
Бо рядка спочатку взагалі не було.
Вона побачила, що результат умови змінився.
Зʼявився «фантомний» рядок.
Це дуже важливо.

Бо багато бізнес-правил звучать не як:

«Онови конкретний рядок з id = 123».

А як:

«перевір, що не існує активного бронювання на цю кімнату»;

«перевір, що немає іншого активного trial»;

«перевір, що немає payout у статусі processing»;

«перевір, що кількість активних сесій менша за ліміт»;

«перевір, що на цю дату ще немає запису».

Тобто ми перевіряємо не один рядок.
Ми перевіряємо умову.
І якщо база не захищає цю умову від паралельних вставок, у нас може виникнути баг.

Інколи правильне рішення — не піднімати isolation level, а змінити модель даних.

Наприклад, замість перевірки COUNT(*) = 0 можна додати UNIQUE constraint:
CREATE UNIQUE INDEX unique_room_bookingON bookings(room_id, booking_date);

Тоді навіть якщо дві транзакції одночасно спробують створити бронювання, база не дозволить записати дубль.
Одна транзакція виграє.
Інша отримає помилку.
А application має правильно її обробити.
Це часто краще, ніж покладатися лише на перевірку в коді.

Коротко

Класична таблиця isolation levels корисна, але вона не пояснює все.

На цьому етапі важливо запамʼятати три базові проблеми:

• Dirty read — ми прочитали незакомічені дані, які можуть бути відкочені.
• Non-repeatable read — ми двічі прочитали той самий рядок і побачили різні значення.
• Phantom read — ми двічі виконали запит за умовою і побачили нові рядки.

Але це ще не всі небезпечні аномалії.

Найчастіше в реальному backend нас боляче бʼють не тільки dirty/non-repeatable/phantom reads.

Нас бʼють:

• lost update;
• write skew;
• неправильні read-modify-write операції;
• відсутність constraints;
• неправильний retry;
• сліпа віра в default isolation level.

Тому далі треба розібрати аномалії, які особливо часто виникають у production-системах.

Продовжуємо з блоку про аномалії, які найчастіше болять у production: lost update, read-modify-write, write skew, read skew.

Аномалії, які частіше за все болять у реальних системах

Dirty read, non-repeatable read і phantom read — це хороша база для розуміння isolation levels.
Але в реальних backend-системах часто болять інші сценарії.

Особливо ті, де application робить щось на кшталт:

read → calculate → write

Тобто:

1. прочитали поточний стан;
2. прийняли рішення в коді;
3. записали новий стан назад.

На папері це виглядає нормально.
Але при паралельному виконанні така модель легко ламається.

Lost update: коли одна транзакція непомітно затирає результат іншої

Повернемось до прикладу з балансом.
На рахунку є 100.
Дві транзакції одночасно хочуть списати по 30.

Transaction A                         Transaction B
-------------                         -------------
BEGIN;                                BEGIN;
SELECT balance                        SELECT balance
FROM accounts                         FROM accounts
WHERE id = 1;                         WHERE id = 1;
-- 100                                -- 100
calculate 100 - 30 = 70               calculate 100 - 30 = 70
UPDATE accounts                       UPDATE accounts
SET balance = 70                      SET balance = 70
WHERE id = 1;                         WHERE id = 1;
COMMIT;                               COMMIT;

Фінальний баланс — 70.
А мав би бути 40.

Одна зміна фактично загубилася.
Звідси й назва — lost update.

Проблема тут не в тому, що база не вміє робити UPDATE.
Проблема в тому, що application прочитав значення, порахував нове значення у себе в коді, а потім записав результат назад.

Тобто ми зробили операцію не як атомарну зміну в базі, а як read-modify-write цикл між application і database.

Чому UPDATE balance = balance - 30 часто краще за read-modify-write

Поганий варіант виглядає так:

SELECT balance
FROM accounts
WHERE id = 1;
-- application рахує newBalance = balance - 30

UPDATE accounts
SET balance = :newBalance
WHERE id = 1;

Тут між SELECT і UPDATE є вікно, в яке може зайти інша транзакція.

Кращий варіант:

UPDATE accounts SET balance = balance - 30 WHERE id = 1;

Тут зміна відбувається всередині самої бази.
База не просто записує готове значення 70.
Вона застосовує операцію до поточного значення рядка.

Для багатьох сценаріїв це вже сильно зменшує ризик lost update.
Але цього все одно може бути недостатньо.

Наприклад, якщо треба перевірити, що баланс не стане негативним, краще не робити окремий SELECT, а включити умову прямо в UPDATE:

UPDATE accounts SET balance = balance - 30 WHERE id = 1   AND balance >= 30;

Після цього application перевіряє, скільки рядків було оновлено.
Якщо 1 — списання успішне.
Якщо 0 — грошей недостатньо або запис не знайдено.
Це дуже важливий патерн.

Ми не питаємо базу:

«Скільки там грошей? Я зараз сам порахую.»

Ми кажемо:

«Спробуй списати 30, але тільки якщо баланс дозволяє.»

Це ближче до того, як треба думати про транзакції в конкурентному середовищі.
Не просто читати стан і вірити, що він не змінився.
А формулювати зміну так, щоб база могла перевірити умову в момент оновлення.

Lost update — це не тільки про гроші

Баланс — зручний приклад, але проблема набагато ширша.
Lost update може зʼявитися майже будь-де.

Наприклад, лічильник:

views = 100
User A reads 100
User B reads 100
User A writes 101
User B writes 101

Мало бути 102.
Стало 101.

Або налаштування користувача:

Transaction A змінює email notifications.
Transaction B змінює language preference.
Обидві читають старий profile object.
Обидві записують весь profile object назад.
Одна зміна затирає іншу.

Або inventory:

На складі 5 одиниць товару.
Два замовлення одночасно читають stock = 5.
Обидва вирішують, що товар є.
Обидва записують stock = 4.
Фактично продали 2 одиниці, але склад зменшився тільки на 1.

Або job processing:

Тому lost update — це не академічна проблема з підручника.

Це один із найпрактичніших багів у системах, де є паралельні запити.

Як зазвичай захищаються від lost update

Є кілька підходів.

Перший — атомарний UPDATE з умовою, як у прикладі з балансом:
UPDATE accounts SET balance = balance - 30 WHERE id = 1   AND balance >= 30;

Другий — constraint у базі.

Наприклад:
ALTER TABLE accounts ADD CONSTRAINT balance_non_negative CHECK (balance >= 0);
Constraint не замінює всю бізнес-логіку, але добре захищає базові інваріанти.

Третій — pessimistic locking.
Тобто ми явно блокуємо рядок перед тим, як приймати рішення:
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;

Ідея проста:

«Я зараз буду приймати рішення на основі цього рядка.
Не давайте іншій транзакції змінити його, поки я не закінчу.»

Це може бути правильним рішенням для критичних операцій.
Але воно зменшує паралельність і може створити contention або deadlocks, якщо використовувати його бездумно.

Четвертий — optimistic locking.

Наприклад, у таблиці є колонка version:

UPDATE accounts SET balance = 70,     version = version + 1 WHERE id = 1   AND version = 5;

Якщо інша транзакція вже змінила цей рядок і підняла version, наш UPDATE оновить 0 рядків.

Це означає:

«Я працював зі старою версією даних. Треба перечитати і спробувати ще раз або повернути помилку.»

Optimistic locking добре працює там, де конфлікти рідкі.
Pessimistic locking — там, де конфлікти часті або помилка занадто дорога.
Ми ще повернемось до цього окремо в розділі про locking.

Поки важливо зафіксувати:

Isolation level — це не єдиний інструмент захисту від lost update.

Часто правильна відповідь — це комбінація:

• правильного SQL;
• constraints;
• locks;
• optimistic locking;
• retry logic;
• і нормального моделювання даних.

Write skew: коли транзакції не конфліктують напряму, але ламають правило

Lost update ще відносно легко зрозуміти.
Дві транзакції працюють з одним і тим самим рядком.
Одна затирає результат іншої.
Але є більш підступна проблема — write skew.

Вона виникає тоді, коли дві транзакції читають спільний набір даних, приймають рішення, а потім змінюють різні рядки.
Тобто прямого конфлікту по одному рядку немає.
Але бізнес-правило все одно ламається.

Класичний приклад — лікарі на чергуванні.

Є таблиця:

CREATE TABLE doctors_on_call (     doctor_id BIGINT PRIMARY KEY,     is_on_call BOOLEAN NOT NULL );

Дані:

Правило:

На чергуванні має залишатися хоча б один лікар.

Транзакція A:

BEGIN;

SELECT COUNT(*)
FROM doctors_on_call
WHERE is_on_call = true;
-- бачить 2

UPDATE doctors_on_call
SET is_on_call = false
WHERE doctor_id = 1;

COMMIT;

Транзакція B одночасно:

BEGIN;

SELECT COUNT(*)
FROM doctors_on_call
WHERE is_on_call = true;
-- теж бачить 2

UPDATE doctors_on_call
SET is_on_call = false
WHERE doctor_id = 2;

COMMIT;

Фінальний стан:

Кожна транзакція окремо виглядала правильною.
Кожна бачила, що є ще один лікар.
Кожна оновила свій рядок.
Ніхто не перезаписав чужий update.
Але бізнес-інваріант зламаний.

Це і є write skew.

Чому write skew складніший за lost update

При lost update ми часто можемо сказати:

«Окей, треба захистити конкретний рядок.»

Але при write skew проблема не в одному конкретному рядку.
Проблема в правилі, яке залежить від набору рядків.

У прикладі з лікарями треба захистити не просто doctor_id = 1 або doctor_id = 2.

Треба захистити умову:

WHERE is_on_call = true

Або навіть ширше:

«У цій групі має залишатися хоча б один активний запис.»

Саме тому write skew часто проявляється в сценаріях:

• «має залишитися хоча б один active admin»;
• «має бути не більше N активних сесій»;
• «не можна мати два активні subscription plans»;
• «не можна запустити payout, якщо вже є payout у processing»;
• «у кімнаті не може бути двох бронювань на той самий слот»;
• «ліміт не має бути перевищений сумою кількох операцій».

І це вже не завжди лікується простим row lock.
Бо ви можете заблокувати рядок, який оновлюєте.
Але інша транзакція оновлює інший рядок.
З точки зору бази, прямого конфлікту може не бути.

Як захищатися від write skew

Є кілька підходів.
Перший — підняти isolation level до Serializable, якщо база справді дає serializable-гарантії для такого сценарію.

Ідея serializable в тому, що результат паралельного виконання має бути таким, ніби транзакції виконались у якомусь послідовному порядку.

У прикладі з лікарями це означає, що база має не дозволити обом транзакціям успішно закомітитись.
Одна може пройти.
Інша має отримати serialization failure і бути повторена або відхилена.

Але тут важливо:
Serializable — це не кнопка «зробити все правильно безкоштовно».
Він може вимагати retry logic.
Може зменшити throughput.
Може створити більше abort/conflict ситуацій.
І різні бази реалізують його по-різному.

Другий підхід — змінити модель даних і додати constraint.

Наприклад, для бронювання кімнати краще мати унікальний індекс:

CREATE UNIQUE INDEX unique_room_booking ON bookings(room_id, booking_date);
Тоді база сама не дозволить два бронювання на один слот.

Для «один active subscription» можна зробити partial unique index, якщо база це підтримує:
CREATE UNIQUE INDEX unique_active_subscription ON subscriptions(user_id) WHERE status = 'ACTIVE';

Це дуже сильний підхід.
Бо ми переносимо інваріант ближче до даних.
Не просто перевіряємо правило в application code.
А змушуємо базу фізично не дозволити некоректний стан.

Третій підхід — явно блокувати спільний ресурс.

Наприклад, якщо правило стосується групи, можна мати окремий рядок-групу і блокувати його:
SELECT * FROM hospital_shifts WHERE shift_id = 123 FOR UPDATE;

Після цього всі зміни лікарів у цій зміні проходять через один locked parent row.
Це зменшує паралельність, але робить правило контрольованим.

Четвертий підхід — advisory locks, якщо база їх підтримує.

Наприклад, можна блокувати логічний ключ:
lock("shift:123")

Це вже більш прикладний механізм, і ним легко зловживати.
Але в деяких сценаріях він зручний, коли треба захистити не один конкретний рядок, а логічну бізнес-сутність.

Read skew: коли ми бачимо суміш різних моментів часу

Є ще одна проблема, яку часто недооцінюють, — read skew.

Вона виникає тоді, коли транзакція або набір запитів читає дані, які логічно мають бути узгодженими між собою, але фактично бачить суміш різних станів.

Уявімо переказ між двома рахунками.

Спочатку:
Account A = 100 Account B = 100 Total = 200

Інша транзакція переказує 50 з A на B:
Account A = 50 Account B = 150 Total = 200

Якщо наш звіт читає A до переказу, а B після переказу, він може побачити:
Account A = 100 Account B = 150 Total = 250

Такого цілісного стану системи ніколи не було.
Але звіт його побачив.

Це особливо небезпечно для:

• фінансових звітів;
• reconciliation;
• risk calculations;
• аналітичних snapshotʼів;
• consistency checks;
• batch processing.

Тут не обовʼязково є dirty read.
Ми можемо читати тільки закомічені дані.
Проблема в тому, що різні частини читання відповідають різним моментам часу.
Саме тому для звітів часто потрібен стабільний snapshot.

Тобто не просто:

«Читай тільки закомічене».

А:

«Читай узгоджену картину бази на певний момент часу».

Serialization anomaly: коли результат неможливо пояснити жодним послідовним порядком

Найзагальніший клас проблем — serialization anomalies.

Простими словами:

Паралельні транзакції дали результат, який неможливо отримати, якщо виконати ці транзакції одну за одною в будь-якому порядку.

Це вже більш формальна тема, але ідея важлива.

Serializable isolation намагається гарантувати саме це:
результат має бути таким, ніби транзакції виконались послідовно.
Не обовʼязково фізично послідовно.
База може виконувати їх паралельно.
Але фінальний результат має бути еквівалентний якомусь serial order.

Наприклад:

• спочатку A, потім B;
• або спочатку B, потім A.

Якщо ж результат не відповідає жодному з таких порядків, це serialization anomaly.
Багато складних багів з транзакціями — це саме такі ситуації.
Ми не завжди називаємо їх цим терміном у роботі.

Зазвичай кажемо простіше:

«Дані якось дивно розʼїхались».

Але під капотом часто проблема саме в тому, що паралельне виконання не було еквівалентне коректному послідовному виконанню.

Чому retry — це частина дизайну, а не «костиль»

Коли база виявляє конфлікт, вона не завжди може «розрулити» його автоматично.

Іноді правильне рішення — скасувати одну транзакцію.

Наприклад:

• через deadlock;
• через serialization failure;
• через optimistic locking conflict;
• через unique constraint violation при конкурентній вставці;
• через compare-and-set failure.

Для application це виглядає як помилка.

Але не кожна така помилка означає, що система зламалась.

Іноді це нормальна частина concurrency control.

Наприклад:

У такій моделі retry — це не сором.
Це частина контракту.

Особливо при Serializable, optimistic locking, Redis WATCH, Cassandra lightweight transactions або будь-яких CAS-подібних механізмах.

Але retry має бути продуманим.

Не можна просто безкінечно повторювати будь-яку операцію.

Треба враховувати:

• чи операція idempotent;
• чи були зовнішні side effects;
• чи можна безпечно повторити запит;
• скільки разів retry допустимий;
• чи потрібен backoff;
• що показати користувачу після кількох невдалих спроб.

Наприклад, повторити чистий database update часто можна.
А повторити виклик payment provider без idempotency key — дуже погана ідея.
Тому retry logic має проектуватись разом із транзакційною моделлю.

Коротко

Окрім dirty read, non-repeatable read і phantom read, у реальних системах часто болять інші аномалії:

• Lost update — одна транзакція затирає результат іншої.
• Write skew — транзакції змінюють різні рядки, але разом ламають бізнес-правило.
• Read skew — ми читаємо суміш даних з різних моментів часу.
• Serialization anomaly — результат паралельного виконання неможливо пояснити жодним послідовним порядком.

Важлива думка:

Не всі проблеми транзакцій лікуються одним isolation level.

Іноді краще допомагають:

• атомарний UPDATE;
• WHERE-умова прямо в update;
• UNIQUE або CHECK constraint;
• pessimistic locking;
• optimistic locking;
• serializable isolation;
• retry;
• idempotency;
• зміна моделі даних.

Далі можна повернутися до isolation levels і вже нормально розібрати, що саме гарантує кожен рівень.
Рівні ізоляції: що насправді гарантує кожен рівень
Тепер, коли ми розібрали основні аномалії, можна повернутися до isolation levels.

Бо самі назви рівнів мало що дають.

Read Committed звучить безпечно.

Repeatable Read звучить ще безпечніше.

Serializable звучить як «максимальний захист».

Але в реальності важливо не те, як рівень називається, а що саме він дозволяє і забороняє.

Почнемо з класичних рівнів:

• Read Uncommitted;
• Read Committed;
• Repeatable Read;
• Serializable.

І будемо дивитись на них не як на абстрактну таблицю, а як на набір відповідей на практичні питання:

• чи можна читати незакомічені дані?
• чи може один і той самий рядок змінитись всередині транзакції?
• чи можуть зʼявитися нові рядки, які підпадають під уже перевірену умову?
• чи можна втратити update?
• чи можна зламати бізнес-інваріант через write skew?
• чи потрібні retry?
• як це поводиться в різних базах?

Read Uncommitted: рівень, який майже ніколи не варто використовувати

Read Uncommitted — найслабший рівень ізоляції в класичній SQL-моделі.

Його ідея проста:

Транзакція може бачити зміни інших транзакцій ще до того, як вони зробили COMMIT.

Тобто dirty read тут дозволений.

На практиці це означає, що ви можете прочитати дані, які через секунду будуть відкочені.

Наприклад:

Transaction A                         Transaction B
-------------                         -------------
BEGIN;
UPDATE accounts
SET balance = 0
WHERE id = 1;
                                      BEGIN;
                                      SELECT balance
                                      FROM accounts
                                      WHERE id = 1;
                                      -- бачить 0
ROLLBACK;

Transaction A                         Transaction B
-------------                         -------------
BEGIN;
SELECT balance
FROM accounts
WHERE id = 1;
-- 100
                                      BEGIN;
                                      UPDATE accounts
                                      SET balance = 50
                                      WHERE id = 1;
                                      COMMIT;
SELECT balance
FROM accounts
WHERE id = 1;
-- 50
COMMIT;

BEGIN;

SELECT balance
FROM accounts
WHERE id = 1;
-- application рахує новий баланс

UPDATE accounts
SET balance = :newBalance
WHERE id = 1;

COMMIT;

Transaction A                         Transaction B
-------------                         -------------
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT balance
FROM accounts
WHERE id = 1;
-- 100
                                      BEGIN;
                                      UPDATE accounts
                                      SET balance = 50
                                      WHERE id = 1;
                                      COMMIT;
SELECT balance
FROM accounts
WHERE id = 1;
-- все ще 100
COMMIT;

SELECT *
FROM bookings
WHERE room_id = 10
  AND booking_date BETWEEN '2026-05-01' AND '2026-05-31'
FOR UPDATE;

Але retry треба робити обережно.
Безпечний retry можливий тоді, коли транзакція не встигла зробити незворотні зовнішні side effects.

Наприклад, якщо транзакція тільки читала і писала в базу — повторити її зазвичай можна.

Але якщо всередині ви вже викликали payment provider, відправили email або відправили повідомлення в зовнішню систему, retry може створити дублікати.

Тому при сильній ізоляції треба думати не тільки про базу.
Треба думати про межу транзакції в application flow.

Добрий патерн:

• всередині database transaction змінюємо тільки стан у базі;
• зовнішні side effects робимо через outbox/event після commit;
• всі зовнішні операції робимо idempotent;
• serialization failures і deadlocks обробляємо через контрольований retry.

Тобто Serializable — це сильний інструмент.

Але не магічний режим.

Класична таблиця isolation levels, але з обережністю

Тепер можна повернутися до таблиці.
У спрощеному вигляді вона виглядає так:

Isolation level	Dirty read	Non-repeatable read	Phantom read
Read Uncommitted	можливий	можливий	можливий
Read Committed	ні	можливий	можливий
Repeatable Read	ні	ні	залежить від БД
Serializable	ні	ні	ні

Але для реального життя я б додав ще одну, чеснішу таблицю:

Питання	Read Committed	Repeatable Read / Snapshot	Serializable
Чи бачу я тільки закомічені дані?	так	так	так
Чи стабільний snapshot протягом транзакції?	зазвичай ні	зазвичай так	так
Чи можливий lost update?	залежить від запиту і БД	залежить від БД	зазвичай має бути попереджений або транзакція впаде
Чи можливий write skew?	так	часто так при Snapshot Isolation	ні, якщо Serializable справжній
Чи потрібні retry?	іноді	іноді	часто
Чи можна не думати про locks/constraints?	ні	ні	теж ні

Останній рядок найважливіший.

Навіть Serializable не означає, що можна забути про constraints, idempotency, retry і нормальну модель даних.

Він просто дає сильнішу гарантію щодо паралельного виконання транзакцій.

Як вибирати isolation level на практиці

Я б не радив починати з питання:

«Який isolation level найкращий?»

Краще починати з іншого:

«Яку аномалію я не можу дозволити в цьому сценарії?»

Наприклад.

Якщо ви просто читаєте профіль користувача для UI, Read Committed може бути достатньо.
Якщо ви формуєте фінансовий звіт, вам може знадобитися стабільний snapshot.
Якщо ви оновлюєте баланс, краще використовувати атомарний UPDATE з умовою або lock.
Якщо ви перевіряєте унікальність бізнес-правила, краще додати constraint або unique index.
Якщо ви захищаєте інваріант, який залежить від кількох рядків, можливо, потрібен Serializable, explicit lock або зміна моделі даних.
Якщо конфлікти рідкі, optimistic locking може бути кращим.
Якщо конфлікти часті і помилка дорога, pessimistic locking може бути надійнішим.

Тобто isolation level — це тільки один шар.

Повна відповідь часто складається з кількох шарів:

data model
+ constraints
+ transaction boundary
+ isolation level
+ locks
+ retry
+ idempotency
+ monitoring

BEGIN;
-- do something
COMMIT;