1 min lesson
Idempotency and late-arriving events
Match each case in "Idempotency and late-arriving events" to the signal and response that fit it.
Step 1 of 2
Idempotency and late-arriving eventsthe corrections problem
Two failure modes cause most consumption-billing pain. Double-billing comes from re-ingesting the same event and you defend against it with the unique event id and dedup. Late-arriving events are subtler: a usage event with an occurred_at inside a period that arrives after you have already invoiced or closed that period.
You cannot rewrite a closed invoice. You issue a correction.
Late event still lands inside the open aggregate.
Rating picks it up; the invoice is simply correct.
No correction needed.
The invoice is immutable history.
Issue a credit memo or a true-up line on the next invoice.
Revenue catch-up is booked in the current period, not back-dated.
A dedicated metering/rating layer usually lives between the product and the ERP rather than inside either. The product should not carry pricing logic - pricing changes far more often than product code and must be auditable. The ERP should not ingest millions of raw token events - it wants summarized journal entries. The rater is the seam that turns a firehose of events into a few priced, traceable lines and keeping it separate is what lets each side change independently.