Move from flat to usage-based billing

WHAT THIS TESTS This probes whether you understand that billing is a correctness-critical system, not a feature. Money creates hard requirements: no lost events, no double charges, full auditability, and graceful handling of disputes and refunds.

A GOOD ANSWER COVERS Separate metering from billing. Each billable action emits a usage event carrying customer id, metric, quantity, timestamp, and an idempotency key. Do not count in the hot request path; publish events to a durable stream like Kafka or a queue. An aggregation job rolls events into per-customer, per-period totals, deduplicating by idempotency key and tolerating retries and late-arriving events using event time, not arrival time. A rating step applies the price plan, including tiers and free allowances, to produce a charge. Finally push usage records or invoices to the payment provider, then reconcile what they billed against what you computed. Store raw events immutably for audit and dispute resolution.

COMMON WRONG ANSWERS Incrementing a counter synchronously and charging immediately, which loses data on crashes and cannot be re-run. Aggregating by arrival time, so a delayed event lands in the wrong invoice. Ignoring idempotency, producing double charges on retries. Forgetting refunds, plan changes mid-cycle, and proration.

LIKELY FOLLOW-UPS How do you handle an event that arrives after the invoice closed? How do you guarantee exactly-once counting under retries? How do you reconcile with Stripe and detect drift?

ONE CONCRETE EXAMPLE A customer makes ten thousand API calls. Each call enqueues an event with a unique key. A nightly job sums events by event-time into the June period, dedupes keys, applies a tiered price, and posts a usage record to Stripe. A late event arriving on July 1 for June 30 is detected by its timestamp and added to June via an adjustment, keeping the invoice correct and auditable.