Как синхронные вызовы внутри транзакции могут привести к неконсистентности данных?

Транзакция в базе данных — это последовательность операций, которая должна удовлетворять свойствам ACID: атомарность, согласованность, изоляция и долговечность. Ключевая идея в том, что все изменения внутри транзакции либо применяются целиком, либо откатываются полностью, обеспечивая целостность данных.

Проблема синхронных вызовов

Синхронный вызов — это операция, которая блокирует выполнение кода до своего завершения. Примеры: HTTP-запрос к другому сервису, чтение файла с диска, вызов удалённого API. Когда такой вызов выполняется внутри транзакции, возникают следующие риски:

• Длительное удержание блокировок: Транзакция удерживает блокировки на изменяемых строках или таблицах на всё время выполнения внешнего вызова. Это резко увеличивает вероятность deadlock и снижает общую пропускную способность системы.
• Нарушение атомарности: Если после успешной записи в БД внешний синхронный вызов завершается с ошибкой, транзакция может быть откачена. Однако эффект от вызова (например, отправленное письмо или списанный баланс во внешнем сервисе) уже невозможно отменить автоматически. Это ломает принцип "всё или ничего".
• Нарушение изоляции: Другие транзакции видят промежуточные изменения первой транзакции, пока та ждёт ответа от внешнего сервиса, если уровень изоляции недостаточно строгий. Это может привести к чтению "грязных" или неконсистентных данных.

Пример кода с проблемой

// Псевдокод, иллюстрирующий антипаттерн
beginTransaction();
try {
    // 1. Операция с базой данных
    updateAccountBalance(userId, -amount);

    // 2. СИНХРОННЫЙ вызов к внешнему платежному шлюзу
    let paymentResult = synchronousHttpCall('https://payment-gateway/charge', { amount });
    if (!paymentResult.success) {
        throw new Error('Payment failed');
    }

    // 3. Еще одна операция с БД
    logTransaction(userId, amount);
    commitTransaction();
} catch (error) {
    rollbackTransaction(); // Откатывает шаги 1 и 3, но не шаг 2!
    // Платеж уже списан у шлюза, а баланс пользователя восстановлен — неконсистентность.
}

Как избежать проблемы

Основной подход — выносить взаимодействие с внешними системами за пределы транзакции базы данных. Можно использовать паттерны:

• Саги (Sagas): Разбить процесс на отдельные транзакции, связанные через события или сообщения. В случае ошибки запускается компенсирующая транзакция.
• Асинхронная коммуникация: Поместить задачу во внутреннюю очередь (например, RabbitMQ, Kafka) и завершить транзакцию БД. Отдельный worker обработает вызов внешнего сервиса асинхронно.
• Двухфазный коммит (2PC): Для систем, поддерживающих распределённые транзакции, но это сложно и редко применяется в микросервисных архитектурах.

Вывод: Синхронные вызовы внутри транзакции — это архитектурный антипаттерн, который ведёт к хрупкости системы и неконсистентности данных. Для интеграции с внешними сервисами следует использовать асинхронные, идемпотентные и компенсируемые паттерны, сохраняя транзакции БД короткими и быстрыми.