<b>Почему хранить балансы в MySQL — это билет в ад, а не архитектура</b>

<b>Почему хранить балансы в MySQL — это билет в ад, а не архитектура</b>

Ledger — это не «табличка с балансом», а журнал событий. Если вы пишете туда только текущее число, вы сами себе выносите приговор: холды, отмены, частичные возвраты и chargeback’и превращают строку в мусор. Идемпотентность или смерть.

Нормальная схема держит не баланс, а проводки: debit/credit, ссылка на бизнес-операцию, статус, время, корреляционный id. Баланс — производная, которую можно собрать из леджера или закешировать отдельно. Если в MySQL лежит одно поле balance, вы теряете причину изменения и не можете нормально объяснить расхождение между фронтом, выплатами и сверкой.

Типовые косяки:
— обновление balance через `UPDATE ... SET balance = balance + X` без блокировок и уникального ключа на идемпотентность;
— хранение «успешного платежа» без отдельного ledger entry;
— смешивание авторизации, capture и settlement в одной колонке status;
— отсутствие audit trail: потом бухгалтерия орет, а логи — истина.

Сильная модель: append-only ledger, уникальный business key, транзакция на запись проводки, отдельный слой для расчетного баланса и сверки. MySQL тут не враг, враг — попытка сделать из нее бухгалтерскую систему на костылях.

Если у вас баланс — это одно число в одной таблице, вы уже копите инцидент. Делайте журнал, а не иллюзию порядка.