Рівні ізоляції, блокування і конкурентність

Що таке конкурентність (concurrency) і чому це болюча тема саме для QA?

Конкурентність — це ситуація, коли кілька транзакцій торкаються тих самих даних в одну мить. Класичний приклад: двоє касирів одночасно продають той самий останній квиток, обидва бачать «1 у наявності» й обидва проводять оплату. База даних дає інструменти, щоб такі колізії не псували дані, і водночас дозволяє свідомо послабити суворість заради швидкодії. Для QA тема з подвійним дном: по-перше, серед найдорожчих і найважчих для відтворення продакшн-багів — саме конкурентні (подвійне списання, від'ємний залишок, «зникле» оновлення профілю); по-друге, з рівнів ізоляції росте частина флаку в інтеграційних тестах. Головна складність у тому, що ці баги не ловляться сценарієм «клік за кліком»: вони виникають лише коли двоє діють одночасно.

Назвіть аномалії конкурентного доступу.

Класичних аномалій конкурентного доступу чотири — це небажані ефекти, які транзакція може побачити через дії сусідів; стандарт SQL описує через перші три з них рівні ізоляції. Брудне читання (dirty read) — транзакція бачить чужі незакомічені зміни, які потім відкотяться. Неповторюване читання (non-repeatable read) — той самий рядок, прочитаний двічі в одній транзакції, дає різні значення, бо між читаннями його змінили й закомітили. Фантомне читання (phantom read) — повторний той самий запит повертає інший склад вибірки: з'явився або зник рядок, що підпадає під умову. Окремо стоїть втрачене оновлення (lost update) — це аномалія з класичної критики стандарту (Berenson та ін., 1995): запис однієї транзакції тихо затирає запис іншої. Розуміти треба саме аномалії, бо рівні ізоляції визначаються через них: рівень — це вже наслідок «які з них ми готові терпіти».

Чим брудне читання відрізняється від неповторюваного?

Різниця в тому, чи були зміни закомічені. При брудному читанні транзакція B читає значення, яке транзакція A ще не закомітила: A зменшила баланс зі 100 до 50 без COMMIT, B прочитала 50 і прийняла на ньому рішення, потім A зробила ROLLBACK — балансу 50 не існувало ніколи, B діяла за даними-примарою. При неповторюваному читанні всі зміни цілком легальні й закомічені: B читає баланс 100, за мить A оновлює його до 50 і робить COMMIT, B читає той самий рядок удруге й бачить 50. Тобто брудне читання — про читання «сміття», яке зникне, а неповторюване — про те, що навіть закомічена правда може змінитися посеред твоєї транзакції. Практичний наслідок: звіт, що двічі звернувся до тих самих даних, суперечить сам собі, хоча жодна транзакція не зробила нічого незаконного.

Що таке фантомне читання і чим воно відрізняється від неповторюваного?

Фантомне читання — це коли повторний запит з тією самою умовою повертає інший набір рядків, бо сусідня транзакція вставила або видалила рядок, що підпадає під фільтр. Приклад: B рахує SELECT count(*) FROM orders WHERE status = 'new' і бачить 10, потім A вставляє новий рядок зі status = 'new' і комітить, B повторює той самий запит і бачить 11. Ключова відмінність від неповторюваного читання: там змінюється значення в наявному рядку, а тут — склад вибірки, з'являється «фантом», якого не було мить тому. Саме тому фантоми чіпляються за запити з діапазоном чи предикатом (WHERE, count, агрегати), а не за читання конкретного рядка за id. Від них рятує рівень SERIALIZABLE, а в PostgreSQL — навіть знімковий REPEATABLE READ.

Назвіть рівні ізоляції та які аномалії кожен допускає.

Стандарт SQL визначає чотири рівні за тим, які аномалії на кожному дозволені. READ UNCOMMITTED — найслабший, допускає все, включно з брудним читанням. READ COMMITTED — прибирає брудні читання (бачиш лише закомічене), але допускає неповторюване й фантомне. REPEATABLE READ — додатково прибирає неповторюване читання, лишаючи можливими фантоми (за стандартом). SERIALIZABLE — золотий стандарт: результат гарантовано такий, ніби транзакції виконувалися по черзі, одна за одною, без жодного перекриття. Логіка проста: що вищий рівень — то менше аномалій, але й то більше блокувань, відкатів і черг, тобто конкурентність падає. Це прямий обмін строгості на пропускну здатність системи, і сильний кандидат ілюструє кожну аномалію коротким прикладом на балансі рахунку, а не переказує зазубрену таблицю.

Що таке втрачене оновлення (lost update) і чому воно найпідступніше?

Втрачене оновлення — це коли дві транзакції читають одне значення, кожна рахує нове у застосунку й записує, і другий запис затирає перший. Обидві транзакції читають баланс 100: A рахує 100 - 50 = 50 і комітить, B рахує 100 - 30 = 70 і комітить. Списання A зникло — мало бути 20, а стало 70. Найпідступніше воно тому, що ламає дані без жодного ROLLBACK і без помилки: обидві транзакції завершилися успішно, а гроші «намалювалися». Корінь проблеми — патерн «прочитай у застосунок → порахуй → запиши», де обидві сторони виходять зі застарілого прочитаного значення. Саме тому lost update плутають із «база загубила оновлення», хоча база відпрацювала чесно — інваріант порушив патерн доступу в коді.

Як не допустити lost update?

Є три робочі ліки, і кандидат має знати щонайменше два. Перший — песимістичне блокування: SELECT ... FOR UPDATE блокує рядок ексклюзивно ще на читанні, тож друга транзакція чекає й читає вже оновлене значення, а не застаріле. Другий — атомарний вираз: замість «прочитати-порахувати-записати» зробити UPDATE balance = balance - 30 одним запитом, де база сама перечитує актуальне значення під блокуванням. Третій — оптимістичне блокування через версію рядка: додати колонку version, оновлювати з умовою WHERE version = <прочитане> і на нуль оновлених рядків повторити транзакцію. На високому рівні ізоляції рятує ще серіалізаційна помилка: PostgreSQL на конфлікті кидає could not serialize access (SQLSTATE 40001), і той, хто пише другим, отримує помилку замість тихого затирання. Вибір між песимістичним і оптимістичним підходом залежить від очікуваної частоти конфліктів: часті конфлікти — блокуй, рідкісні — версіонуй.

Який рівень ізоляції за замовчуванням у PostgreSQL і MySQL?

PostgreSQL за замовчуванням працює на READ COMMITTED, MySQL (InnoDB) — на REPEATABLE READ. Це не педантизм, а джерело реальних багів: однаковий SQL поводиться по-різному залежно від СУБД і рівня за замовчуванням. Причому PostgreSQL строгіший, ніж вимагає стандарт: його REPEATABLE READ побудований на знімку транзакції й прибирає навіть фантомні читання, а не лише неповторювані. Інтерв'юер цим питанням перевіряє, чи ти взагалі стикався з відмінностями СУБД, а не читав абстрактний стандарт. Практичний висновок: тест має ганяти ту саму СУБД і рівень, що й прод, інакше конкурентний баг може відтворюватися лише в одному із середовищ.

Чому однаковий SQL може по-різному поводитися на Postgres і MySQL?

Бо в них різні рівні ізоляції за замовчуванням і різна реалізація цих рівнів. PostgreSQL стартує з READ COMMITTED, де між двома читаннями світ може змінитися; MySQL/InnoDB — з REPEATABLE READ, де звичайний SELECT бачить знімок від першого читання в транзакції. Ба більше, READ UNCOMMITTED у Postgres просто працює як READ COMMITTED (брудних читань не буває взагалі), а в MySQL це справжній рівень із можливими брудними читаннями. Тому сценарій «на стейджі зелено, на проді валиться» часто пояснюється не кодом, а тим, що локально ти на SQLite чи Postgres із дефолтом, а прод — MySQL на REPEATABLE READ. Перше, що робить QA, побачивши плаваючий конкурентний баг між середовищами — звіряє СУБД і рівень ізоляції, а не лізе в код застосунку.

Поясніть MVCC своїми словами.

MVCC (Multi-Version Concurrency Control — багатоверсійність) — це механізм, завдяки якому база дає кожній транзакції узгоджений «знімок» даних без глобального блокування на читання. Ідея проста: коли транзакція оновлює рядок, база не затирає старе значення, а створює нову версію рядка поряд, і стара версія живе, доки її ще хтось може читати. Ключова фраза, яку хочуть почути на співбесіді: читання не блокує запис, запис не блокує читання. У PostgreSQL кожен рядок має службові позначки xmin/xmax (id транзакцій, що його створили й застарили), а непотрібні старі версії — це «мертві» рядки, які згодом прибирає VACUUM; у MySQL InnoDB старі версії лежать в undo-логах, а знімок реалізований через read view. Для QA MVCC пояснює дві дивні на позір речі: довга транзакція-читач роздуває базу мертвими версіями (бо VACUUM не має права прибрати те, що вона ще бачить), і два клієнти в один момент часу бачать різні дані — обидва праві, просто дивляться на різні знімки.

Що означає фраза «читання не блокує запис»?

Це головний наслідок MVCC: читання й запис того самого рядка не стають у чергу один за одним. Поки транзакція A переписує рядок (створює нову версію), транзакція B спокійно читає стару версію — їй не треба чекати завершення A. Кожна транзакція бачить узгоджений знімок бази на певний момент, ніби фотографію, і зміни сусідів на цій фотографії не проявляються. Це різко підвищує пропускну здатність системи порівняно зі старою схемою «читання бере блокування», де звіт міг заморозити півсистеми. Але важливо розуміти межу: MVCC знімає лише конфлікт «читання проти запису»; конфлікт «запис проти запису» лишається, бо два UPDATE того самого рядка одночасно неможливі — там уже вмикаються блокування.

Чим відрізняються спільне (S) та ексклюзивне (X) блокування рядка?

Спільне блокування (shared, S) означає «я читаю, не чіпайте на запис»: кілька транзакцій можуть тримати S на одному рядку одночасно, воно береться явно через SELECT ... FOR SHARE. Ексклюзивне (exclusive, X) означає «я змінюю, стійте всі»: тільки одне на рядок, воно блокує і інші X, і S, береться автоматично при UPDATE/DELETE і явно через SELECT ... FOR UPDATE. Простими словами: S-блокування сумісні між собою (читати можуть кілька транзакцій одночасно), X-блокування ексклюзивне (пише лише одна, і вона блокує всіх). Ця сумісність і визначає, хто чекатиме в черзі: два SELECT ... FOR SHARE пройдуть паралельно, а SELECT ... FOR UPDATE на вже заблокованому на запис рядку зачекає. На практиці QA стикається з X-блокуваннями частіше, бо саме вони стоять за симптомом «запит завис» — насправді він чекає на рядок, який тримає інша відкрита транзакція.

Навіщо потрібен SELECT ... FOR UPDATE?

Це правильні ліки від lost update у патерні «прочитай, порахуй, запиши». Звичайний SELECT під MVCC не блокує рядок, тож дві транзакції можуть прочитати те саме значення й затерти одна одну. SELECT ... FOR UPDATE бере ексклюзивне блокування рядка ще на читанні: транзакція A блокує рядок, і транзакція B на своєму SELECT ... FOR UPDATE чекає, доки A завершиться, після чого читає вже оновлене значення. Тобто це спосіб перетворити небезпечну гонку «читання-запис» на впорядковану чергу. Альтернатива без явного блокування — атомарний UPDATE balance = balance - 30 одним виразом, де база сама перечитує актуальне значення під блокуванням; FOR UPDATE потрібен, коли між читанням і записом є нетривіальна логіка в застосунку, яку не виразити одним UPDATE.

Що таке deadlock і чи це завжди баг?

Deadlock — це коли дві транзакції захопили по рядку й кожна чекає на рядок, який тримає інша: A заблокувала рядок 1 і чекає рядок 2, B заблокувала рядок 2 і чекає рядок 1. Утворюється цикл очікування, який сам не розв'яжеться. СУБД виявляє цей цикл і примусово відкочує одну з транзакцій-жертв, звільняючи іншу; помилки впізнавані — PostgreSQL кидає deadlock detected, MySQL — Deadlock found when trying to get lock; try restarting transaction (код 1213). Ні, deadlock не завжди баг: під навантаженням це очікуваний ефект, і правильна реакція застосунку на нього — повторити транзакцію. Тому, побачивши такі помилки в логах, QA спершу перевіряє, чи є в коді ретрай, і лише потім заводить дефект — бо баг тут зазвичай саме відсутність ретраю, а не сам deadlock. Знизити частоту deadlock-ів допомагає єдиний порядок захоплення рядків у всіх транзакціях.

Чому послідовний тест не ловить конкурентні баги і як писати тест на race condition?

Звичайний послідовний тест бачить світ очима одного клієнта: POST /orders, потім GET /orders, перевірка — зелено, бо в один момент часу діяв лише один клієнт. Гонка ж виникає тільки за одночасності, тож її треба створити навмисно: вистрілити кількома запитами паралельно (у Playwright/TypeScript це Promise.all над кількома API-запитами до одного ресурсу) і перевірити інваріант, який має вціліти за будь-якого порядку. Три дисципліни чесного тесту гонок: перевіряй інваріант, а не конкретний порядок («виграв рівно один» і «залишок не від'ємний», а не «перший запит виграв», бо переможець недетермінований); пам'ятай, що гонка імовірнісна — один зелений прогін нічого не доводить, бо колізія могла просто не збігтися в часі; підвищуй конкурентність і повторюй тест у циклі. І головне — не плутай гонку в застосунку з флаком у самому тесті: нестабільність через sleep-и й криву синхронізацію тесту — це його проблема, а нестабільний результат саме на інваріанті даних — сигнал реального конкурентного бага.

Що таке write skew і який рівень ізоляції від нього рятує?

Write skew — це аномалія, коли дві транзакції читають той самий набір даних, а пишуть у різні рядки, разом порушуючи спільний інваріант. Класика: правило «хоча б один лікар має бути на чергуванні», двоє чергових одночасно читають «нас двоє, можна піти», кожен знімає себе — і на чергуванні не лишається нікого. Підступність у тому, що навіть знімкова ізоляція (REPEATABLE READ у PostgreSQL) її не ловить: кожна транзакція бачить консистентний знімок і пише в свій рядок, формального конфлікту запису немає. Від write skew рятує лише SERIALIZABLE: у Postgres він відстежує залежності читання-запису й кидає серіалізаційну помилку на небезпечній парі транзакцій. Це питання senior-рівня: воно показує, що кандидат розуміє межу знімкової ізоляції й не вважає REPEATABLE READ панацеєю.

Чим оптимістичне блокування відрізняється від песимістичного?

Песимістичне блокування виходить із припущення «конфлікт імовірний, тож захопимо рядок наперед»: транзакція бере SELECT ... FOR UPDATE, і решта чекають у черзі, доки вона завершиться. Оптимістичне виходить із «конфлікт рідкісний, тож не блокуємо, а перевіримо на записі»: читаємо рядок разом із версією (version чи updated_at), а на оновленні ставимо умову WHERE version = <прочитане>; якщо хтось устиг змінити рядок, оновиться нуль рядків — і транзакцію треба повторити. Песимістичний підхід простіший і надійніший при частих конфліктах, але тримає блокування й ризикує deadlock-ами та чергами; оптимістичний майже не має накладних витрат при рідкісних конфліктах, але вимагає логіки ретраю в застосунку. Вибір — це компроміс: гарячий рядок, який усі оновлюють (лічильник, залишок останнього товару), краще блокувати, а рідко конкурентні сутності (профіль користувача) — версіонувати. Для QA це означає різні тест-сценарії: для песимістичного перевіряємо, що друга транзакція коректно дочекалася, для оптимістичного — що конфлікт дав очікувану помилку чи ретрай, а не тихе затирання.

Три кейси, де конкурентність вирішує, зелений тест чи полювання за примарою: відтворення lost update двома сесіями psql (і як FOR UPDATE його лікує), тест на race condition у Playwright з перевіркою інваріанта, і тріаж симптому «запит завис / на проді валиться» за таблицею рішень. Скрізь — що дивитися і чому.

Кейс 1. Відтворити lost update руками і полагодити його

Найкраще відчути аномалію — відтворити її у двох сесіях бази вручну. Відкрий два термінали psql до однієї БД і програй патерн «прочитай — порахуй — запиши» з перекриттям. Нехай стартовий баланс — 100.

-- Сесія A                          -- Сесія B
BEGIN;                              BEGIN;
SELECT balance FROM accounts        SELECT balance FROM accounts
  WHERE id = 1;    -- бачить 100       WHERE id = 1;    -- теж бачить 100
-- застосунок рахує 100 - 50 = 50   -- застосунок рахує 100 - 30 = 70
UPDATE accounts SET balance = 50
  WHERE id = 1;
COMMIT;                            
                                    UPDATE accounts SET balance = 70
                                      WHERE id = 1;
                                    COMMIT;
-- Підсумок: balance = 70. Списання A зникло, мало бути 20.

Обидві транзакції завершилися успішно, помилки не було — а гроші «намалювалися». Це і є lost update: запис B вийшов зі застарілого прочитаного значення й затер запис A. Зверни увагу, що на дефолтному READ COMMITTED у PostgreSQL база тут нічого не порушила — інваріант зламав патерн доступу в застосунку, а не СУБД.

Тепер увімкни блокування — заміни звичайний SELECT на блокувальний:

-- Сесія A                          -- Сесія B
BEGIN;                              BEGIN;
SELECT balance FROM accounts
  WHERE id = 1 FOR UPDATE;  -- 100, рядок заблоковано ексклюзивно
                                    SELECT balance FROM accounts
                                      WHERE id = 1 FOR UPDATE;  -- ЧЕКАЄ на A
UPDATE accounts SET balance = 50
  WHERE id = 1;
COMMIT;                            -- A відпустила блокування
                                    -- лише тепер B прочитала 50, рахує 50 - 30 = 20
                                    UPDATE accounts SET balance = 20
                                      WHERE id = 1;
                                    COMMIT;
-- Підсумок: balance = 20. Правильно.

Що дивитися і чому:

• FOR UPDATE перетворив гонку на чергу. Сесія B зависла на SELECT ... FOR UPDATE, доки A не закомітила; після цього B прочитала вже оновлене значення 50, а не застаріле 100. Так само працює атомарний UPDATE accounts SET balance = balance - 30 WHERE id = 1 — база сама перечитує актуальне значення під блокуванням.
• Той самий сценарій на REPEATABLE READ у Postgres лікується інакше. Там друга транзакція вже на своєму UPDATE отримає помилку could not serialize access due to concurrent update (SQLSTATE 40001) — і застосунок має її повторити, а не впасти. Перемагає той, хто закомітив першим.
• Це і є оракул для баг-репорту. Якщо в застосунку баланс «губиться» без помилок у логах — відтвори цей мінімальний двосесійний сценарій проти тієї самої СУБД і рівня, що на проді. Відтворилося — дефект у патерні доступу коду, а не «база загубила дані».

Кейс 2. Playwright: спровокувати гонку й перевірити інваріант

Послідовний тест POST → GET гонку не побачить, бо в один момент діє один клієнт. Щоб зловити подвійне списання останнього товару, конкурентність треба створити навмисно — вистрілити пачкою паралельних запитів і перевірити інваріант, що має вціліти за будь-якого порядку.

import { test, expect } from '@playwright/test';

// Гонка: 20 паралельних спроб купити останній товар
test('останній товар не продається двічі', async ({ playwright }) => {
  const api = await playwright.request.newContext({ baseURL: process.env.BASE_URL });
  await api.post('/api/inventory/reset', { data: { itemId: 'X', stock: 1 } });

  const attempts = Array.from({ length: 20 }, () =>
    api.post('/api/orders', { data: { itemId: 'X', qty: 1 } }),
  );
  const responses = await Promise.all(attempts);

  const created = responses.filter((r) => r.status() === 201);
  expect(created).toHaveLength(1); // рівно одна купівля успішна

  const stock = await (await api.get('/api/inventory/X')).json();
  expect(stock.available).toBe(0); // залишок не пішов у мінус
});

Що дивитися і чому:

• Перевіряй інваріант, а не переможця. Асерт — «створено рівно один» і «залишок не від'ємний», а не «перший запит виграв». Хто саме переміг — недетерміновано, і закладатися на це не можна.
• Один зелений прогін нічого не доводить. Гонка імовірнісна: колізія могла просто не збігтися в часі. Підвищуй конкурентність (більше паралельних запитів), заганяй тест у цикл повторів, а якщо застосунок має тестові хуки із затримкою — використовуй їх, щоб розширити «вікно» гонки.
• Той самий підхід — на ідемпотентності API. Паралельні повтори одного запиту з Idempotency-Key мають дати один результат, а не N списань — суміжна перевірка тим самим Promise.all.
• Не сплутай сигнали. Якщо тест то падає, то ні через власні sleep-и й криву синхронізацію — це флак самого тесту. А нестабільний результат саме на інваріанті даних (created.length то 1, то 2) — це вже сигнал реального конкурентного бага в продукті.

Кейс 3. Тріаж: «запит завис» і «на проді валиться»

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

Що дивитися і чому:

• «Висить» — це майже завжди чужа транзакція, а не повільний запит. Запит чекає на ексклюзивне блокування рядка. Класичний винуватець — забутий незакритий BEGIN у клієнті на кшталт DBeaver, де вимкнено autocommit. Перевіряється через системні вʼю блокувань, а не через EXPLAIN.
• «На проді валиться» — спершу СУБД і рівень, потім код. READ COMMITTED у Postgres і REPEATABLE READ у MySQL дають різну видимість між читаннями, тож той самий код відтворює баг лише в одному середовищі. Тестуй на тій самій СУБД і рівні, що й прод.
• Deadlock у логах — не привід для паніки. Правильна реакція застосунку на нього — повторити транзакцію. Тому баг тут — відсутність ретраю, а не сам deadlock; знизити частоту допомагає єдиний порядок захоплення рядків.
• Дисципліна одна на всі рядки: не заявляй причину без доказу. «Схоже на lost update, двосесійний сценарій відтворює втрату» коштує рівно стільки, скільки під ним відтворення й логів.

Аномалії конкурентного доступу

• Розумію, що рівні ізоляції описують не механізми, а аномалії — небажані ефекти від дій сусідніх транзакцій, і саме аномалії треба знати першими.
• Можу пояснити брудне читання (dirty read) і чому воно про читання незакоміченого «сміття», яке потім відкотиться.
• Знаю різницю між неповторюваним читанням (non-repeatable read) і фантомним (phantom read): перше — змінилося значення в рядку, друге — змінився склад вибірки.
• Можу пояснити втрачене оновлення (lost update) — псує дані без жодного ROLLBACK і без помилки — і що це аномалія з класичної критики стандарту (Berenson та ін.), а не з базової таблиці рівнів.

Рівні ізоляції

• Знаю чотири рівні за зростанням строгості (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE) і які аномалії кожен дозволяє, виводячи це з логіки «вище — строгіше», а не зазубрюючи таблицю.
• Розумію компроміс: що вищий рівень, то менше аномалій, але то більше блокувань, відкатів і черг — конкурентність падає.
• Можу пояснити, що SERIALIZABLE гарантує результат, ніби транзакції виконувалися по черзі, і чому за це платять продуктивністю.

Дефолти й відмінності СУБД

• Знаю рівні за замовчуванням: PostgreSQL — READ COMMITTED, MySQL/InnoDB — REPEATABLE READ.
• Розумію, що PostgreSQL строгіший за стандарт (його REPEATABLE READ на знімку прибирає навіть фантоми), а READ UNCOMMITTED у Postgres працює як READ COMMITTED — тоді як у MySQL це справжній рівень із брудними читаннями.
• Розумію, чому тест має ганяти ту саму СУБД і рівень, що й прод, і чому інакше виникає «на стейджі зелено, на проді валиться».

MVCC

• Можу пояснити MVCC своїми словами (оновлення не затирає рядок, а створює нову версію поряд) і знаю ключову фразу «читання не блокує запис, запис не блокує читання».
• Розумію, що кожна транзакція бачить власний узгоджений знімок, тож два клієнти в один момент можуть бачити різні дані — і обидва праві.
• Можу пояснити, чому довга транзакція-читач роздуває базу мертвими версіями і навіщо потрібен VACUUM (undo-логи в InnoDB).

Блокування і deadlock

• Знаю різницю між спільним (S, FOR SHARE) та ексклюзивним (X, FOR UPDATE, автоматично при UPDATE/DELETE) блокуванням рядка.
• Розумію, що MVCC знімає конфлікт «читання проти запису», але «запис проти запису» лишається, і що SELECT ... FOR UPDATE чи атомарний UPDATE ... = ... - N — ліки від lost update.
• Знаю, що таке deadlock, що СУБД сама відкочує транзакцію-жертву, і що правильна реакція — ретрай, а баг — це відсутність ретраю.
• Впізнаю повідомлення: deadlock detected (Postgres), Deadlock found ... try restarting transaction код 1213 (MySQL), could not serialize access SQLSTATE 40001.

Тестування гонок

• Розумію, чому послідовний тест не ловить конкурентні баги і що гонку треба створювати навмисно через паралельні запити (Promise.all) з перевіркою інваріанта («виграв рівно один»), а не конкретного переможця.
• Розумію імовірнісну природу гонки: один зелений прогін не доводить її відсутності, тому потрібні висока конкурентність і повтори.
• Не плутаю гонку в застосунку з флаком у самому тесті (sleep-и й крива синхронізація — проблема тесту, нестабільний інваріант даних — сигнал реального бага), а «баг застосунку» — з «дефолтом СУБД»/«чергою за блокуванням»: спершу звіряю СУБД, рівень і відкриті транзакції, а вже потім заводжу дефект.