ACID — это не про базу данных, это про границы ответственности

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

Atomicity — операция не бывает выполнена наполовину. Списали деньги со счёта А, но не зачислили на счёт Б из-за сбоя сети — без атомарности деньги просто исчезают.

Consistency — после коммита данные удовлетворяют всем ограничениям: внешним ключам, чекам, уникальным индексам. Это не про логическую консистентность бизнес-правил вообще, а конкретно про инварианты, которые знает сама БД.

Isolation — одновременные транзакции не видят промежуточных состояний друг друга. Степень изоляции настраивается уровнем — от read uncommitted до serializable, и чем выше уровень, тем больше блокировок и ниже параллелизм.

Durability — закоммиченные данные переживут падение сервера. Обеспечивается через WAL (write-ahead log): сначала пишем в журнал на диск, потом применяем к данным.

На собеседовании часто спрашивают: «а что будет, если упадёт сервер между коммитом и ответом клиенту?» Транзакция уже закоммичена (Durability это гарантирует), но клиент не получил ответ — он не знает об этом. Отсюда вопрос про идемпотентность: клиент должен уметь безопасно повторить запрос, не создав вторую транзакцию.

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

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки