<b>Хранить балансы в MySQL — это не архитектура, а приглашение к двойным списаниям</b>

<b>Хранить балансы в MySQL — это не архитектура, а приглашение к двойным списаниям</b>

Ledger — это не таблица с колонкой balance. Это журнал событий, где каждое движение денег должно быть неизменяемым, а текущий баланс — производным расчетом, а не источником истины. Как только вы начинаете делать UPDATE balance = balance - 100, у вас появляется гонка, ретраи, дубль вебхука и веселый праздник для саппорта.

Нормальная схема держится на трех вещах:
— append-only записи, без правок задним числом;
— идемпотентный ключ на каждую операцию;
— атомарная проводка в одной транзакции: дебет, кредит, ссылка на событие, статус.
Идемпотентность или смерть. Без нее любой повторный запрос превращает ledger в казино.

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

Проверка простая: можно ли пересобрать баланс из событий, не трогая ручные патчи? Если нет — вы уже проиграли.

—
Если понравилось — посмотри @payment_methods_arb_arb