Пометровый биллинг ломается не на цене, а на учете события в моменте

Пометровый биллинг ломается не на цене, а на учете события в моменте

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

Критический набор правил:
— событие должно иметь монотонный счетчик или временное окно, иначе повторная доставка ломает объем;
— стоимость рассчитывается по снимку тарифа, а не по «текущему состоянию»;
— все пересчеты пишутся как корректирующие проводки, а не переписывают прошлую историю;
— лимиты и throttling должны срабатывать до начисления, а не после.

Для потоков с высокой частотой лучше считать микропакеты: агрегировать usage за короткий интервал, но сохранять первичный event log. Так вы снижаете нагрузку на биллинг-движок и не теряете трассировку. Отдельно проверьте границу суток, смену тарифа внутри сессии, отложенную доставку событий и частичный отказ брокера — именно там возникает revenue leakage.

Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.