ACID

ACID — это акроним четырёх свойств, которые должна гарантировать транзакция базы данных, чтобы считаться надёжной: Atomicity / Атомарность (транзакция либо выполняется полностью, либо не имеет никакого эффекта — при сбое посередине не остаётся частичных обновлений), Consistency / Согласованность (транзакция всегда переводит базу данных из одного допустимого состояния в другое, никогда не нарушая заданные ограничения, такие как внешние ключи или уникальность), Isolation / Изоляция (параллельные транзакции не мешают друг другу — выполняющаяся транзакция не видит незафиксированные изменения другой транзакции) и Durability / Долговечность (после фиксации транзакция переживает последующий сбой — данные действительно записаны в долговременное хранилище, а не просто хранятся в памяти). Почему это важно для разработчиков AI/SaaS-продуктов: гарантии ACID — это то, что делает безопасным строить биллинг, подписки и любую логику, связанную с деньгами, на реляционной базе данных, не беспокоясь постоянно о таких крайних случаях, как «а что, если сервер упадёт ровно между списанием денег с карты и записью подписки». PostgreSQL, MySQL и практически все основные реляционные базы данных полностью соответствуют ACID; это одна из главных причин, по которым реляционные базы данных остаются выбором по умолчанию для основных транзакционных данных SaaS даже в эпоху, полную новых, более специализированных хранилищ данных. Большинство хранилищ данных, смежных с AI, делают иной компромисс: многие векторные базы данных и системы NoSQL сознательно ослабляют некоторые гарантии ACID (обычно согласованность или изоляцию) в обмен на более высокую пропускную способность записи или более лёгкое горизонтальное масштабирование — законный компромисс для эмбеддингов и логов событий, но неправильный компромисс для записи о подписке клиента. Как это работает: транзакции явно очерчиваются (`BEGIN`, затем последовательность операторов, затем `COMMIT` или `ROLLBACK`), а движок базы данных сам обеспечивает соблюдение всех четырёх свойств внутри себя — используя упреждающую запись в журнал (write-ahead logging) для долговечности и атомарности, блокировки или многоверсионное управление параллелизмом (MVCC, которое использует Postgres) для изоляции и проверку ограничений для согласованности. Практический пример: процессу оформления заказа в SaaS нужно и списать средства с платёжного метода, и создать запись о подписке — две операции, которые должны либо обе завершиться успешно, либо обе провалиться вместе, но никогда не только одна из них. Обёртывание обеих операций в одну транзакцию базы данных (`BEGIN; INSERT INTO payments ...; INSERT INTO subscriptions ...; COMMIT;`) гарантирует атомарность: если сервер упадёт или произойдёт ошибка после вставки платежа, но до вставки подписки, вся транзакция откатывается, не оставляя «осиротевшей» записи о платеже без соответствующей подписки — сбой, который иначе потребовал бы хрупкой ручной логики сверки для обнаружения и исправления постфактум.