Кратко: задача — обеспечить, чтобы при параллельной обработке платежей по одному заказу сумма платежей никогда не превысила total заказа и чтобы один и тот же реальный платёж не был записан дважды. Для этого нужны: (1) атомарная логика обновления состояния заказа и записи платежа в рамках одной транзакции; (2) защита от повторной отправки (idempotency); (3) правильный выбор либо явной блокировки (пессимистичный подход), либо контроля сериализуемости/опробования (оптимистичный подход). Ниже — развернутый разбор вариантов, рисков и рекомендаций.

1) Основные требования и примитивы

Транзакция: вставка записи в payments и изменение агрегированного состояния заказа (например, столбца paid или проверка суммы) должны быть в одной транзакции.Уникальный idempotency_key (соответствующая уникальная констрейнт) на payments для защиты от повторной отправки того же платёжного события.Atomic update: лучше избегать “SELECT сумма; IF OK INSERT” в двух отдельных операциях без блокировки — это подвержено гонкам.Ограничения целостности: foreign key payments.order_id -> orders.order_id, (опционально) check-constraint orders.paid <= orders.total или контроль через логику транзакции.

2) Вариант A — пессимистическая блокировка (рекомендуется, простая и надёжная)
Описание:

Берём блокировку на строку заказа, проверяем остаток, вставляем платёж и обновляем paid, затем коммитим.
Пример (Postgres / совместимые SQL):
BEGIN;
SELECT paid, total FROM orders WHERE order_id = :id FOR UPDATE;
IF paid + :amount > total THEN
ROLLBACK; -- reject / return error
ELSE
INSERT INTO payments(payment_id, order_id, amount, paid_at, idempotency_key) VALUES (...);
UPDATE orders SET paid = paid + :amount WHERE order_id = :id;
COMMIT;
END IF;
Плюсы:Простая логика, гарантированная последовательность для одного order_id.Не требуется SERIALIZABLE.
Минусы:Блокировка строки: при высокой конкурентности запросы к одному заказу будут последовательно ждать; при блокировках нескольких строк — риск дедлоков (решается фиксированным порядком захвата блокировок).FOR UPDATE в Postgres блокирует только существующие строки; если нужна защита от вставки новой строки (фантомов), лочить соответствующие индексы/предикаты или использовать advisory lock.

Варианты улучшения:

Использовать pg_advisory_xact_lock(order_id) вместо SELECT ... FOR UPDATE — даёт явную логическую блокировку на уровне приложения, не затрагивая схему.

3) Вариант B — атомарный UPDATE (без отдельного SELECT)
Описание:

Использовать условный UPDATE, который увеличивает paid только если новое значение не превысит total; если UPDATE вернул 0 строк — откат.
Пример:
BEGIN;
-- попробуем атомарно увеличить
UPDATE orders
SET paid = paid + :amount
WHERE order_id = :id AND paid + :amount <= total
RETURNING paid;
IF no rows returned THEN
ROLLBACK; -- превышение или нет заказа
ELSE
INSERT INTO payments(..., idempotency_key) VALUES (...);
COMMIT;
END IF;
Плюсы:Короткая критическая секция, меньше окон для гонок.Нет отдельного SELECT ... FOR UPDATE.
Минусы:Нужно гарантировать, что INSERT payments не создаст повторной записи при повторных попытках (используйте idempotency_key UNIQUE).В ряде СУБД возможны тонкости с порядком аннотации блокировок, но в Postgres/Innodb UPDATE захватывает нужные блокировки.

4) Вариант C — оптимистичный контроль + SERIALIZABLE
Описание:

Работать в SERIALIZABLE (или в Postgres REPEATABLE READ с семантикой сериализации) и при конфликте повторять транзакцию.
Пример:
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- читаем текущую сумму (или суммируем payments)
-- вставляем payment
-- проверяем что сумма не превышена
COMMIT; -- в случае write-skew СУБД выбросит serialization error => retry
Плюсы:Нет явных блокировок, хорошо масштабируется при малой вероятности конфликтов.
Минусы:При высокой нагрузке частые abort и retry (стоимость).В Postgres REPEATABLE READ — это snapshot isolation, возможен write-skew; нужен именно SERIALIZABLE.

5) Idempotency и защита от двойной записи

Клиент должен посылать уникальный idempotency_key (например, UUID) для каждого пользовательского платёжного события.В таблице payments сделать UNIQUE(idempotency_key, client_id) или UNIQUE(idempotency_key) в зависимости от модели.При повторной попытке вставки: INSERT ... ON CONFLICT DO NOTHING или проверка существования и возврат существующей записи.
Это покрывает повторные запросы от клиента (например, при таймаутах).

6) Уровни изоляции — воздействие на проблему

READ UNCOMMITTED: потенциально опасен (грязные чтения). Не рекомендуется.READ COMMITTED: обычно достаточен если вы используете SELECT ... FOR UPDATE или условный UPDATE, т.к. вы явно берёте блокировку при чтении/обновлении.REPEATABLE READ:
В MySQL/InnoDB REPEATABLE READ использует next-key locking и предотвращает фантомы для многих сценариев.В Postgres REPEATABLE READ — snapshot isolation, допускает write-skew: два параллельных транзакции могут увидеть старое состояние и оба записать изменения, превысив ограничение.SERIALIZABLE: самый строгий — гарантирует отсутствие write-skew, но приводит к ошибкам сериализации (serialization_failure) и требует логики повторной попытки. Хорош для критичных invariants, если можно терпеть откаты и ретраи.

Рекомендации по выбору:

Для Postgres: либо использовать SELECT ... FOR UPDATE / advisory locks (пессимистично), либо использовать SERIALIZABLE и be prepared to retry (оптимистично).Для MySQL/InnoDB: условный UPDATE или FOR UPDATE + подходящая индексация часто достаточно; но надо учитывать next-key locks и возможность блокировок.

7) Дедлоки и производительность

Дедлоки происходят когда транзакции захватывают несколько блокировок в разном порядке. Избегать: всегда брать блокировки в одном и том же порядке (например, по order_id возрастанию).Сделайте транзакции короткими: минимизируйте время между SELECT ... FOR UPDATE и COMMIT.Не блокируйте большие таблицы или сканируйте много строк под блокировками.Мониторьте ожидающие блокировки и логи дедлоков.

8) Дополнительные меры целостности

Отдельный check-constraint orders.paid <= orders.total можно поддерживать, если paid обновляется атомарно транзакцией; это действует как защита на уровне БД (если попытка поставить paid > total — DB откажет). Но не используйте только CHECK между таблицами.Триггеры: можно валидировать сумму payments <= total в AFTER INSERT триггере — но такой триггер может всё равно пропустить межтранзакционные гонки, если нет адекватных блокировок/уровня изоляции.

9) Практическая рекомендуемая стратегия (сочетание безопасности и производительности)

Требование: клиент присылает уникальный idempotency_key.В транзакции:
1) Попробовать атомарный UPDATE orders: UPDATE orders SET paid = paid + :amount WHERE order_id = :id AND paid + :amount <= total RETURNING paid;
2) Если UPDATE вернул строку — INSERT INTO payments(..., idempotency_key) VALUES (...) (с UNIQUE на idempotency_key). COMMIT.
3) Если UPDATE ничего не вернул — ROLLBACK и вернуть ошибку "превышение суммы".Альтернатива для Postgres: перед шагом 1 делать pg_advisory_xact_lock(order_id), затем делать SELECT/INSERT/UPDATE как в пессимистическом варианте.Добавить мониторинг числа конфликтов/rollback’ов и метрики на частоту повторных попыток idempotency.

10) Итоговая сводка

Самый надёжный и простой путь: транзакция с явной блокировкой строки заказа (SELECT ... FOR UPDATE или pg_advisory_xact_lock) + проверка остатка + вставка платежа + обновление агрегата. Используйте idempotency_key для защиты от повторных попыток.Если нужно лучше масштабироваться и ожидается низкая конкуренция по одному заказу — используйте условный UPDATE или SERIALIZABLE с повторными попытками.Важно также: короткие транзакции, единый порядок захвата блокировок, мониторинг дедлоков/ошибок сериализации.

Если хотите, могу:

Привести готовые SQL-скрипты/хранимую процедуру для Postgres (вариант с FOR UPDATE и вариант с pg_advisory_xact_lock).Показать пример использования idempotency_key с INSERT ... ON CONFLICT.