Usage-based pricing tends to fail in two independent ways at scale: the commercial model can be wrong for the distribution of usage, and the metering system can produce an incorrect quantity. Treating those as one problem makes both harder to diagnose.
Failure mode 1: the average customer is not the distribution
AI and API workloads are bursty. A small number of customers or jobs can consume orders of magnitude more resources than the median. A plan that is profitable at average usage can therefore lose money badly in the tail.
The fix is commercial: model pricing against real usage distributions, not one expected-user number. Measure p50, p90, p99, and the expensive workload classes separately before changing allowances or overage rates.
Failure mode 2: retries become extra usage
At-least-once delivery is normal in distributed systems. If an event is counted again whenever a producer retries after a timeout, revenue becomes a function of network behavior. Use tenant-scoped idempotency at request and record level.
Failure mode 3: delayed events move between periods
Arrival time is not event time. A collector delivering August work in September should not silently change which month owns the quantity. Preserve the event timestamp and aggregate into the period where the work occurred.
Failure mode 4: unique counts forget their members
A monthly active-user meter is not a sum. To keep it correct, the system must remember which members were already counted for as long as late events can still affect that period. Expiring membership state while accepting arbitrarily late events eventually double-counts somebody.
Failure mode 5: current subscription state rewrites history
A customer canceled today may still have legitimate delayed usage from yesterday. Validate an event against the subscription's effective interval at event time. Do not reject historical usage merely because today's status says canceled.
Failure mode 6: invoice generation scans raw events
Raw history is necessary for auditability and reconciliation, but normal billing queries should not need to scan it. Maintain deterministic rollups and let downstream rating or invoicing operate on those compact quantities.
Failure mode 7: the meter and the price are welded together
When application code both measures usage and knows monetary rates, every pricing change becomes an instrumentation release. Emit stable facts first. Version prices downstream.
Where UsageBox fits
UsageBox addresses the metering half of these problems: idempotent ingestion, late events, raw history, subscription/catalog resolution, and monthly rollups. It deliberately does not perform monetary rating or invoice generation today.
That boundary is useful when you want to keep Stripe, Lago, an ERP, or your own billing system while making the usage record independent of it.
Continue with idempotent usage metering, monthly active-user metering, and the usage metering topic hub.