Ledger-архитектура: основы надёжного учёта операций

Если в системе есть деньги, балансы или бонусные счета — нужен ledger-подход, а не «просто update balance».

Проще говоря

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

Базовые принципы

• immutable entries,
• double-entry bookkeeping,
• idempotent posting,
• полный audit trail.

Как это сработало на практике

Коротко про вводные.

Контекст: Сервис выплат страдал от расхождений после ретраев. Переход к ledger-модели с idempotency key и posting journal убрал «плавающие» балансы и упростил расследования.

Архитектурные требования

1. Нельзя редактировать проведённые проводки.
2. Корректировки — только компенсирующими записями.
3. Каждая операция имеет уникальный business id.
4. Reconciliation запускается регулярно.

Частые ошибки

• хранение только текущего баланса,
• отсутствие инвариантов на уровне БД,
• нет ежедневной сверки.

Короткая история из команды

До ledger-модели у команды были «необъяснимые» расхождения балансов после повторных запросов. Каждый такой случай превращался в ручное расследование на полдня. После перехода на неизменяемые проводки и idempotency ключи спорные случаи стали трассируемыми, а доверие к данным вернулось.

Вывод

Ledger-модель делает систему сложнее в начале, но резко снижает риск дорогих финансовых инцидентов.

Почему просто “balance” недостаточно

Текущее значение баланса не объясняет, как система к нему пришла. При спорных операциях или ретраях это критично. Ledger хранит историю проводок и делает каждое изменение трассируемым.

Для финансовых и квази-финансовых доменов это не опция, а база доверия к данным и расследованиям.

Термины простыми словами

• Idempotency — свойство операции давать тот же корректный результат при повторе одного и того же запроса.
• Ledger — модель учёта операций через неизменяемые проводки и полный audit trail, а не «перезапись баланса».

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

Почему это часто проваливается на практике

На бумаге архитектурное решение выглядит логично, но в проде мешают сроки, кросс-командные зависимости и отсутствие явного владельца. Когда решение не встроено в CI, мониторинг и ревью, оно быстро деградирует до «локальной договорённости».

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