<b>Динамический тариф и metered billing ломаются не в UI, а в учете событий</b>

<b>Динамический тариф и metered billing ломаются не в UI, а в учете событий</b>

Реальное время в биллинге — это не «быстро посчитать цену», а гарантировать, что каждый usage-event будет: принят, нормализован, провалидирован и записан без потерь. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Критические узлы схемы:
— ingestion-слой с dedup по event_id и строгой схемой атрибутов;
— pricing-engine, который отделяет расчет тарифа от записи факта потребления;
— ledger, где сумма списания фиксируется отдельно от витрины для UI;
— retry/dunning-логика, чтобы повторная доставка не превратилась в двойное списание.

Для динамического тарифа опасны не только ошибки расчета, но и race conditions: цена может смениться между потреблением и публикацией события. Лечится версионированием прайс-листа, timestamp-based rules и хранением snapshot тарифа вместе с usage-event. Тогда пересчет возможен, а спорные списания объяснимы.

Пометровый биллинг в реальном времени требует еще и контроля лагов: если поток событий отстает, пользователь видит устаревший баланс, а команда — ложную маржу. Нужны backpressure, очереди с гарантированной доставкой и алерты на расхождение между metering и posting слоями 📉

Если система не умеет объяснить, почему именно эта единица usage стоила именно столько, она уже теряет деньги.