Metering & data
Why Your Billing Event ID Should Not Change on a Retry
By the Orvlin team · · 2 min read
Stable billing event ids: what to decide
A request reaches the meter, but its acknowledgement gets lost. The sender assumes failure and tries again. Without a stable identity, a perfectly normal network problem turns into two charges for one action.
Generate the identifier at the point where the billable action is created, then carry it through queues and retries. Deduplication also needs a defined scope and retention window. Two customers using the same local counter must not accidentally cancel out each other’s events.
A concrete scenario
Imagine job J42 costs three credits. It is delivered at 09:00 and retried at 09:02. Both deliveries use J42 and should produce one three-credit charge. Creating a fresh UUID on retry makes the two deliveries look like separate jobs.
A detail teams often miss
A stable ID does not fix every duplicate. If two services independently emit events for the same job, they may assign different IDs. Decide which service owns the billable fact rather than hoping the meter can infer intent.
Before you put this into production
- Persist IDs before attempting delivery.
- Include account identity in the deduplication contract.
- Test retries after the deduplication window expires.
- Track duplicate suppression as an operational signal.
Frequently asked questions
- Can we use the timestamp as an event ID?
- Not safely on its own. Multiple actions can share a timestamp, and retry timestamps can differ. Use an identifier tied to the action itself.