Почему metered billing ломается, когда тариф считают “на лету”

Почему metered billing ломается, когда тариф считают “на лету”

Динамическое тарифообразование и пометровый биллинг выглядят просто: событие пришло — стоимость выросла. На практике система должна одновременно держать консистентность, идемпотентность и низкую задержку, иначе вы получите дубли начислений, расхождения между витриной и ledger, а затем спорные списания.

Ключевой контур обычно такой: поток usage-event’ов попадает в брокер, затем в нормализатор, дальше в агрегатор с окном по времени или объёму, и только потом в pricing-engine. Если промежуточный слой не хранит versioned state, любой ретрай превращается в повторное начисление. Идемпотентный ключ должен собираться не только из event_id, но и из customer_id, meter, периодa и правила тарифа.

Для real-time pricing критичны три правила:
— тариф считается по снимку правил, а не по “текущему состоянию” конфигурации;
— каждый расчёт пишет trace: входные метрики, коэффициент, итоговую сумму;
— корректировка делается отдельной compensating-entry, а не переписыванием прошлого.

Самая частая ошибка — смешивать биллинг и оркестрацию тарифа. Billing должен уметь принять уже рассчитанную цену, проверить кворум данных и провести запись атомарно. Dunning здесь тоже связан: если usage пришёл позже закрытия периода, система обязана доначислить его в следующем цикле без ручной правки.

Если метеринг строится без строгого event ledger, вы не управляете выручкой — вы гадаете по логам.