<b>Распределённый биллинг ломается не в платеже, а в границе консистентности</b>

<b>Распределённый биллинг ломается не в платеже, а в границе консистентности</b>

В биллинге нельзя полагаться на «почти точно» и eventual consistency по умолчанию. Если запись о списании, событие в очереди и изменение баланса живут в разных доменах, у вас появляются фантомные начисления, двойные списания и расхождение ledger с витриной.

Минимальный каркас надёжности такой: — единый источник истины для финансового состояния; — транзакционная запись в ledger до публикации события; — идемпотентный ключ на уровне команды; — outbox-паттерн для доставки в асинхронные контуры; — строгая обработка retry с дедупликацией. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Особое внимание — на границы с внешними шлюзами и внутренними сервисами. Давайте разберем, что происходит с транзакцией в момент сетевого сплита шлюза: клиент уже видит успех, а ваш backend ещё не знает, был ли авторизован платёж. Здесь нужен state machine с явными состояниями: pending, authorized, captured, failed, reversed. Никаких «магических» переходов по косвенным признакам.

Для сверки используйте recon-процессы: периодическое сравнение журнала операций, балансов и внешних реестров. Любое расхождение должно завершаться не ручным исправлением в таблице, а компенсирующей проводкой и следом в audit trail. Грамотно спроектированная dunning-стратегия способна спасти до 15% уходящей регулярной выручки.

Если у системы нет детерминированных переходов, идемпотентных команд и компенсаций, она не масштабируется — она лишь быстрее производит ошибки.