Оглавление

• Зачем бизнесу оптимистическая блокировка
• Оптимистическая vs пессимистическая: когда что выбирать
• Базовый паттерн: «версия записи» в базе
  • Схема таблицы
  • Обновление с проверкой версии
  • Изменение остатков без гонок «прочитал → посчитал → записал»
• HTTP-уровень: ETag и If-Match — как склеить фронт и бэкенд
• Примеры кода: SQL и Node.js (Express + pg)
• Как показывать конфликт пользователю и не бесить UX
• Массовые обновления и батчи без сюрпризов
• Частые ошибки и анти‑паттерны
• Где пессимистические блокировки всё ещё нужны
• Наблюдаемость: метрики конфликтов и тесты гонок
• Миграция в прод без простоя
• Экономика: меньше инцидентов, быстрее разработка
• Чеклист внедрения

Зачем бизнесу оптимистическая блокировка

Гонки в данных — тихий убийца денег и репутации. Две вкладки с одним профилем клиента, два менеджера правят одну сделку, два воркера пересчитывают остатки — в итоге последняя запись «затирает» предыдущую. Теряются поля, счета уходят не теми суммами, пользователи видят неожиданные результаты. Пессимистические блокировки (держать «замок» на строке) гасят часть проблем, но тормозят весь поток: сессии ждут друг друга, таймауты, рост задержек.

Оптимистическая блокировка решает это мягче: никого не стопорим заранее, но перед записью проверяем, что мы редактируем ту же версию данных. Если нет — честно сообщаем о конфликте. В бизнес‑терминах: меньше простоя, меньше инцидентов, предсказуемая производительность.

Оптимистическая vs пессимистическая: когда что выбирать

• Оптимистическая (версия записи, ETag):
  • Подходит в 90% CRUD‑сценариев, где конфликты редки, а скорость важна.
  • Не держит блокировки между чтением и записью.
  • Требует обработки конфликтов (409/412) на уровне API/клиента.
• Пессимистическая (SELECT ... FOR UPDATE):
  • Нужна там, где конфликт почти гарантирован и недопустим: бронирование единичного ресурса «кто первый — тот и взял», перевод денег между счетами в одной транзакции, генерация уникальных номеров в узком месте.
  • Держит блокировки, может снижать пропускную способность.

Правильная система использует оба подхода там, где они уместны.

Базовый паттерн: «версия записи» в базе

Добавляем целочисленное поле version и обновляем строку только если версия совпала. Если обновление прошло — версию инкрементим.

Схема таблицы

-- Пример: карточки товара
CREATE TABLE product (
  id           BIGSERIAL PRIMARY KEY,
  name         TEXT NOT NULL,
  price_cents  BIGINT NOT NULL CHECK (price_cents >= 0),
  stock        BIGINT NOT NULL CHECK (stock >= 0),
  version      BIGINT NOT NULL DEFAULT 0,
  updated_at   TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX product_version_idx ON product (id, version);

Обновление с проверкой версии

-- Клиент прочитал product с version = :prev_version и предлагает изменения
UPDATE product
SET name = $2,
    price_cents = $3,
    updated_at = now(),
    version = version + 1
WHERE id = $1 AND version = $4
RETURNING id, name, price_cents, stock, version, updated_at;

Если обновлено 0 строк — у нас конфликт версий. Возвращаем 409 Conflict или 412 Precondition Failed (см. ниже про ETag).

Изменение остатков без гонок «прочитал → посчитал → записал»

Когда меняем величину инкрементом/декрементом, лучше вообще не читать текущее значение на приложении:

-- Продать 1 единицу, не уходя в минус
UPDATE product
SET stock = stock - 1,
    version = version + 1,
    updated_at = now()
WHERE id = $1 AND stock >= 1
RETURNING id, stock, version;

Так мы избегаем «потери обновления» при параллельных продажах.

HTTP-уровень: ETag и If-Match — как склеить фронт и бэкенд

ETag — это «ярлык версии» ресурса. Клиент получает его при GET и обязан прислать обратно в If-Match при изменении. Сервер сравнивает и либо применяет правку, либо возвращает 412 Precondition Failed.

Правила:

• Жёстко связывайте ETag с полем version (или вычисляйте из version и id). Не используйте updated_at: округления времени дадут фантомные конфликты.
• На чтении: ETag: "{id}:{version}" (можно завернуть в base64/хэш, но не обязательно).
• На записи: требуйте If-Match. Нет заголовка — 428 Precondition Required или 409.

Пример обмена:

GET /api/products/42
→ 200 OK
ETag: "42:3"
{
  "id": 42, "name": "Подписка", "price_cents": 9900, "stock": 15, "version": 3
}

PUT /api/products/42
If-Match: "42:3"
{
  "name": "Подписка PRO", "price_cents": 12900
}
→ 200 OK
ETag: "42:4"
{ ... "version": 4 }

PUT /api/products/42
If-Match: "42:3"
{ "price_cents": 10900 }
→ 412 Precondition Failed
{
  "error": "version_conflict",
  "message": "Ресурс изменился. Обновите данные и повторите."
}

Примеры кода: SQL и Node.js (Express + pg)

Ниже минимальный, но рабочий сервер с двумя эндпоинтами: GET и PUT. Он:

• Выдаёт ETag на чтении.
• Требует If-Match на изменении.
• Обновляет строку только при совпадении версии.

// package.json (важные части)
// {
//   "type": "module",
//   "dependencies": { "express": "^4.18.2", "pg": "^8.11.3" }
// }

import express from 'express';
import { Pool } from 'pg';

const pool = new Pool({ connectionString: process.env.DATABASE_URL });
const app = express();
app.use(express.json());

function makeETag(id, version) {
  return `"${id}:${version}"`; // кавычки — как в HTTP-спеке
}

function parseIfMatch(h) {
  if (!h) return null;
  // ожидаем формат "id:version"
  const m = /^"(\d+):(\d+)"$/.exec(h.trim());
  if (!m) return null;
  return { id: Number(m[1]), version: Number(m[2]) };
}

app.get('/api/products/:id', async (req, res) => {
  const id = Number(req.params.id);
  if (!Number.isFinite(id)) return res.status(400).json({ error: 'bad_id' });
  const { rows } = await pool.query(
    'SELECT id, name, price_cents, stock, version, updated_at FROM product WHERE id = $1',
    [id]
  );
  if (rows.length === 0) return res.sendStatus(404);
  const r = rows[0];
  res.set('ETag', makeETag(r.id, r.version));
  res.json(r);
});

app.put('/api/products/:id', async (req, res) => {
  const id = Number(req.params.id);
  if (!Number.isFinite(id)) return res.status(400).json({ error: 'bad_id' });

  const ifMatch = parseIfMatch(req.get('If-Match'));
  if (!ifMatch || ifMatch.id !== id) {
    return res.status(428).json({ error: 'precondition_required', message: 'Нужен корректный If-Match' });
  }

  const { name, price_cents } = req.body ?? {};
  if (name !== undefined && typeof name !== 'string') return res.status(400).json({ error: 'bad_name' });
  if (price_cents !== undefined && (!Number.isInteger(price_cents) || price_cents < 0)) return res.status(400).json({ error: 'bad_price' });

  const fields = [];
  const values = [id];
  let i = 2;
  if (name !== undefined) { fields.push(`name = $${i++}`); values.push(name); }
  if (price_cents !== undefined) { fields.push(`price_cents = $${i++}`); values.push(price_cents); }
  if (fields.length === 0) return res.status(400).json({ error: 'no_changes' });

  fields.push('updated_at = now()');
  fields.push('version = version + 1');

  values.push(ifMatch.version); // $i

  const sql = `UPDATE product SET ${fields.join(', ')} WHERE id = $1 AND version = $${i} RETURNING id, name, price_cents, stock, version, updated_at`;

  try {
    const { rows } = await pool.query(sql, values);
    if (rows.length === 0) {
      return res.status(412).json({ error: 'version_conflict', message: 'Ресурс изменился. Обновите данные и повторите.' });
    }
    const r = rows[0];
    res.set('ETag', makeETag(r.id, r.version));
    res.json(r);
  } catch (e) {
    console.error(e);
    res.sendStatus(500);
  }
});

const port = process.env.PORT || 3000;
app.listen(port, () => console.log(`API on :${port}`));

Замечания:

• 428 Precondition Required — честный ответ, если клиент не прислал If-Match.
• 412 Precondition Failed — при конфликте версий. Это проще, чем 409, потому что прямо указывает на невыполненную преусловие.

Как показывать конфликт пользователю и не бесить UX

• Мягкий мердж: загрузить актуальную версию, показать дифф, предложить «применить мои правки поверх». Это уместно для текстовых описаний, заметок, комментариев.
• Жёсткое требование перечитать: для чувствительных полей (цена, статус сделки, доступы) лучше попросить пользователя подтвердить изменения, увидев свежие данные.
• Автоповтор бэкграунд‑операций: если конфликт относится к пакетной задаче, можно читать актуальную версию и попытаться применить преобразование ещё раз. Главное — логировать и ограничивать число попыток.

Массовые обновления и батчи без сюрпризов

• По‑строчно, с проверкой версии: для каждой строки своя версия. Пакет из 100 обновлений может частично примениться. Решите заранее, нужно ли «всё или ничего».
• Транзакция + «всё или ничего»: соберите все обновления в одну транзакцию, а при первом конфликте — ROLLBACK. Пользователю верните список конфликтов.
• Опасайтесь «глухих» конфликтов: если вы считали версию N, а кто‑то сделал N+2, ваш алгоритм «применить мою дельту к N+2» должен быть детерминированным.

Частые ошибки и анти‑паттерны

• ETag из updated_at. Микросекундная точность теряется в JSON/JS, часы округляются, появляются ложные конфликты. Используйте отдельное целочисленное поле version.
• ETag как хэш только пользовательских полей. Пропустите служебные атрибуты — словите «невидимые» конфликты. Проще и надёжнее — ETag = id
  .
• Игнор 412 и «перезапиши как есть». Это возвращает вас к «последний записал — тот и прав» и потере данных.
• Злоупотребление xmin в PostgreSQL как «версией». xmin меняется при UPDATE (это хорошо), но его семантика внутренняя для MVCC; перенос данных, логическая репликация, VACUUM/заморозка могут повлиять на предположения. Для API‑контрактов лучше явный version.
• Долгие транзакции: даже при оптимистике не держите транзакции открытыми во время сетевых вызовов — накапливаются «мёртвые версии», растёт нагрузка на автоочистку.

Где пессимистические блокировки всё ещё нужны

• Единичные ресурсы «первый забрал — остальные ждут/проваливаются» (последний билет VIP‑зоны). Используйте UPDATE ... WHERE stock >= 1 RETURNING или SELECT ... FOR UPDATE для явного захвата.
• Комплексные инварианты в нескольких таблицах в одной транзакции (перевод денег между счетами, когда важно «всё или ничего» прямо сейчас).
• Критические секции в коротких операциях, где блокировка длится миллисекунды и гарантирует простую модель.

Оптимистическую блокировку и пессимистическую можно комбинировать: сначала пытаемся по‑оптимистичному, при высокой конкуренции переходим к узкому критическому участку с блокировкой.

Наблюдаемость: метрики конфликтов и тесты гонок

• Метрики API: доля 412/428 от всех PATCH/PUT по ресурсу. Резкий рост — сигнал о конфликтующих процессах или UX‑проблемах.
• Тайминги UPDATE с WHERE version =
  . Если время растёт — посмотрите планы, индексы, и частоту параллельных апдейтов одной строки.
• Логи конфликтов с контекстом: кто и что хотел изменить. Это помогает продукту понять, где пользователи мешают друг другу.
• Нагрузочные и «гоночные» тесты: поднимите N воркеров, которые одновременно меняют одну и ту же сущность. Проверяйте, что нет потери данных и инварианты держатся.

Миграция в прод без простоя

1. Добавьте колонку version с дефолтом 0 и not null. На больших таблицах — в два шага: сначала nullable + backfill + not null + default.
2. Приложение: начните выставлять ETag на GET (на основе version).
3. Постепенно включайте проверку If-Match на изменениях. Сначала логируйте отсутствие/несовпадение, не ломая запросы (режим «тень»).
4. Как только доля клиентов с корректным If-Match станет высокой — начните возвращать 428/412.
5. Обучите фронт: обрабатывать конфликты, показывать дифф/перечитывать.
6. Наблюдайте метрики, настроите алерты на всплески 412.

Экономика: меньше инцидентов, быстрее разработка

• Инциденты из‑за «затёртых» правок исчезают. Службе поддержки не нужно вручную «склеивать» данные.
• Производительность стабильнее: нет очередей ожидания блокировок, бэкенд меньше «колбасит» при пиках.
• Разработчики двигаются быстрее: локальная логика конфликта в одном месте, понятный контракт API, минимум глобальных замков.

Чеклист внедрения

• Есть ли в схеме явная версия записи (BIGINT, not null, default 0)?
• Выставляется ли ETag на GET и требуем ли If-Match на изменениях?
• Обновления пишутся как UPDATE ... WHERE id = ? AND version = ? RETURNING?
• Для инкрементов/декрементов используем операции «на месте», без «прочитал → посчитал → записал»?
• Обработаны коды 412/428 на фронте и в интеграциях? Есть UX для конфликтов?
• Метрики конфликтов, логи контекста, алерты настроены?
• Есть тесты гонок и нагрузочные прогоны?
• Определены зоны, где требуется пессимистическая блокировка или атомарные инварианты в транзакции?

Оптимистическая блокировка и ETag — это простой, но мощный каркас для большинства бизнес‑приложений. Он сохраняет данные, снижает накладные расходы на блокировки и делает поведение системы предсказуемым даже при высокой конкуренции. Внедрив этот паттерн однажды, вы перестанете латать «странные» баги гонок и начнёте быстрее выпускать ценные фичи.