Распределенный биллинг ломается не в расчетах, а в стыках транзакций и повторов

Распределенный биллинг ломается не в расчетах, а в стыках транзакций и повторов

Консистентность в биллинге — это не про «все записали одинаково», а про то, чтобы списание, начисление и статус подписки сходились при сбое сети, ретраях и дубликатах событий. Если платежный шлюз ответил, а БД не успела зафиксировать факт, система уже живет в разъезде состояний.

Базовый набор защиты выглядит так: — идемпотентный ключ на каждую бизнес-операцию; — журнал событий как источник истины для денежных движений; — явная модель состояний подписки: pending, active, grace, failed, canceled; — outbox/inbox для надежной доставки между сервисами. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Самая опасная ошибка — смешивать финансовую транзакцию и изменение пользовательского статуса в одном неатомарном потоке без компенсации. Тогда при частичном отказе вы легко получаете либо лишнее списание, либо активный доступ без оплаты. Дальше начинается ручная сверка, а это почти всегда revenue leakage и спорные кейсы в поддержке.

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

Если у вас нет строгой модели состояний и идемпотентного контура на каждом внешнем интеграционном стыке, биллинг рано или поздно начнет «дублировать правду» и деньги.