Что такое транзакция

Транзакция защищает систему от частично примененных изменений. Представьте перевод денег. Нужно списать сумму с одного счета и зачислить на другой. Если списание прошло, а зачисление нет, данные стали неконсистентными.

Поэтому короткий ответ можно дать так: транзакция объединяет несколько операций в одно надежное действие. Результат либо фиксируется полностью, либо полностью отменяется.

Классический SQL-пример выглядит так:

BEGIN;

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

UPDATE accounts
SET balance = balance + 100
WHERE id = 2;

COMMIT;

Если между двумя UPDATE произошла ошибка, сервер должен сделать ROLLBACK. Практический смысл простой. Пользователь не должен получить состояние, где деньги уже списались, но не дошли до получателя.

ACID это набор гарантий, которыми часто описывают транзакции.

• Atomicity: все операции применяются или все отменяются.
• Consistency: данные переходят из одного валидного состояния в другое.
• Isolation: параллельные транзакции не должны ломать результат друг друга.
• Durability: после фиксации результат сохраняется даже при сбое.

На интервью не нужно читать лекцию про каждый уровень изоляции. Достаточно показать, что транзакция нужна не для удобства кода, а для защиты целостности данных.

Для Frontend Developer лучше не ограничиваться фразой, что это тема бэкенда. Дайте определение, приведите пример и сразу покажите, как транзакции влияют на клиентский код.

Фронтенд обычно не открывает транзакцию в базе данных. Он вызывает API, а сервер уже решает, какие изменения выполнить внутри BEGIN, COMMIT и ROLLBACK или через другой механизм.

Но клиент отвечает за состояние экрана. Если вы сразу показываете успех после клика, а сервер потом откатывает операцию, пользователь увидит ложный результат. Если вы разрешаете повторный submit без защиты, можно создать два заказа или две попытки оплаты. Если запрос завершился таймаутом, результат неизвестен. Сервер мог уже зафиксировать изменения.

Один POST /orders может выглядеть для клиента как одно действие, но внутри сервер может создать заказ, зарезервировать товар и запустить оплату. Эти шаги должны быть согласованы на сервере.

Отдельная проблема для фронтенда это повтор. Пользователь может потерять сеть, не получить ответ и нажать кнопку снова. Если операция не идемпотентна, повтор может создать дубль. Поэтому для платежей и заказов часто используют Idempotency-Key или другой серверный механизм защиты от повторной обработки.

Важно: отмена клиентского запроса через AbortController не означает автоматический откат серверной транзакции. Она только прекращает ожидание ответа на клиенте. После такого сценария безопаснее перечитать данные или запросить статус операции, а не показывать финальный результат наугад.

Что можно сказать на интервью:

Я понимаю, что фронтенд не гарантирует транзакционность базы. Но я должен учитывать контракт API: не показывать финальный успех до подтверждения, защищать форму от двойной отправки, корректно обрабатывать таймауты и делать rollback, если использую optimistic UI.

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

Поэтому строгая ACID-транзакция между всеми сервисами часто оказывается слишком дорогой или сложной. На практике используют Saga. Каждый шаг выполняется отдельно, а при ошибке запускаются компенсирующие действия. Например, если оплата прошла, но резерв товара не удался, систему нужно привести к безопасному состоянию. Для пользователя это может выглядеть как отмена оплаты или возврат денег.

Важно не обещать, что Saga полностью равна SQL-транзакции. Она помогает управлять процессом, но часто дает eventual consistency. Для фронтенда это значит, что часть операций может быть в статусе обработки, ожидания подтверждения или отмены. Интерфейс должен честно показывать этот статус.

Сильный ответ на этот вопрос состоит из трех частей.

1. Дайте определение: транзакция фиксирует все операции или откатывает все.
2. Назовите ACID и пример: перевод денег, заказ, оплата, резерв товара.
3. Свяжите с фронтендом: состояние загрузки, ошибка, rollback optimistic UI, защита от повторов, обработка таймаута и доверие к API-контракту.

Такой ответ показывает, что вы понимаете и базовую теорию, и последствия для пользовательского интерфейса.