<b>Пометровый биллинг ломается не в расчёте, а в моменте фиксации события</b>

<b>Пометровый биллинг ломается не в расчёте, а в моменте фиксации события</b>

Динамическое тарифообразование в real-time держится на трёх контурах: приём измерений, применение прайс-логики и запись в неизменяемый ledger. Если хоть один контур допускает двойную обработку, вы получаете расхождение между usage, начислением и инвойсом — то самое revenue leakage, которое потом ищут в логах и сверяют руками.

Критично проектировать поток так:
— каждое metering-событие имеет стабильный event_id и версионируемый payload;
— прайс считается по срезу правил, привязанному к моменту потребления, а не к моменту выставления счёта;
— агрегация идёт через идемпотентные upsert/append-операции, а не через «пересчитать всё заново»;
— все пересчёты и ретраи пишут аудит следов, иначе спор по тарифу не восстановить. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Отдельная ловушка — границы тарифа: смена плана посреди интервала, округление по минутам, burst-режимы, free tier и отрицательные корректировки. Если правила не формализованы как детерминированный policy engine, одна и та же сессия может дать разные суммы при повторной обработке. Давайте разберем, что происходит с транзакцией в момент сетевого сплита шлюза: именно там рождаются дубли, пропуски и «серые» начисления.

Практический минимум: event sourcing для usage, отдельный pricing service без побочных эффектов и строгий reconciliation между metering и ledger. Грамотно спроектированная dunning-стратегия способна спасти до 15% уходящей регулярной выручки.