ORIGINAL COMPANY-CONTEXT PRACTICE
Make usage replay billable once
Original practice scenario inspired by AT&T Inc.'s public business context; this is not a reported interview question or a description of its internal systems. A connectivity service receives usage batches from intermittently connected network collectors. A collector retries the same batch after a timeout, and corrections can arrive days later. Design ingestion that supports auditable billing without charging twice.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Treat transport retries and business corrections as separate events. A retry should reuse a stable collector batch identifier; a correction needs its own versioned relationship to the original usage.
Work through it
- Persist the batch identifier, collector identity, checksum, and receipt state before acknowledging. Enforce uniqueness atomically so concurrent retries cannot both create billable rows.
- Write normalized usage and an outbox record in the same transaction. Downstream billing consumes the durable event with its own idempotency key.
- Represent corrections as explicit adjustments with provenance, then reconcile collector totals against accepted usage and billed adjustments.
Tradeoffs to discuss
- Retaining immutable adjustments costs storage but makes replay and customer disputes explainable. Deduplication retention must exceed the permitted retry window.
Common pitfalls
- A random ID generated on every retry defeats deduplication.
- A successful network acknowledgement is not proof that billing completed.