Retrying Billing Events Without Creating New Charges

Billing event retry strategy: what to decide

A network timeout does not tell the producer whether an event was accepted. Generating a new ID on retry can turn one action into two charges. The producer and consumer need a shared identity rule.

Use stable identities scoped to the logical action and retain them through queues and replays. Clarify deduplication windows and what happens when retries outlive them. Distinguish an ingestion acknowledgement from completion of downstream rating.

An example with the numbers exposed

A completed export emits event export-742. The first request times out, so the sender retries export-742 rather than generating export-743. Acceptance of both delivery attempts must still represent one completed export.

The mistake worth avoiding

Retries can amplify outages if every client repeats immediately. Use controlled backoff and monitor pending deliveries. A retry policy needs eventual recovery and exception visibility, not simply infinite repetition.

A practical checklist

• Create IDs before delivery attempts.
• Retain identities through replay.
• Use bounded backoff and recovery queues.
• Reconcile accepted logical actions after outages.