An early-stage AI infrastructure company

The situation

A homegrown token-metering service double-counted events on retry and lost a small but steady trickle of late-arriving usage — enough to make finance distrust the numbers. Neither failure mode was dramatic on its own: a retried request counted twice here, a batch of usage that arrived late and landed in the wrong billing period there. But at millions of events a day, small and steady adds up to a number finance can't reconcile with confidence.

The team had already tried adding retry-deduplication logic on top of the homegrown service, and it introduced its own edge cases. The real problem wasn't a bug to patch — it was that the metering layer had never been built to be idempotent from the start.

How the ledger handles it

Switching ingestion to Kribana's idempotent event ledger means retries become no-ops and events up to 72 hours late still land in the correct billing period. Every usage event carries an idempotency key, so a request that gets retried for any reason — a network blip, a client-side timeout, a redelivered message — is recognized as the same event and counted exactly once, no deduplication logic required on the sending side.

Late-arriving events are handled the same way: usage that shows up hours after it actually happened still gets attributed to the billing period it belongs to, rather than being dropped or miscounted into whatever period happens to be open when it arrives.

What changed

Finance stopped asking if the usage numbers were right. That's the real win — not a faster metering pipeline for its own sake, but a revenue number nobody has to double-check by hand anymore. At the event volume an AI infrastructure company runs, an idempotent ledger isn't an optimization, it's the difference between a billing number finance can close the books on and one they have to caveat.

It changed how the engineering team thinks about scaling too. Adding a new usage-metric type — a new model, a new endpoint, a new unit of compute — used to mean touching the same fragile counting logic that caused the original problem. Now it means defining a new event type against a ledger that was already built to be correct under retries and delays, so growth in the number of things being metered stopped being a source of new bugs.

“Finance stopped asking if the usage numbers were right. That's the real win.”