TENANT BILLING · EVENT IDENTITY
Tenant billing: isolate usage and event identity
Meter eight usage events from two tenants whose clients reuse event ids, and see which tenant each invoice charges.
Your experiment
Acme and globex both send events named u-1 and u-2, because each client numbers its own events. The meter deduplicates on the event id alone, so globex’s usage is dropped as acme’s duplicates. Compare each invoice with true usage, then change the key, the tenant source and the late-event rule.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Fictional usage at a fictional 2 cents per 1,000 tokens; one billing period closing on day 30. The event list is fixed: one client retry of acme u-2, one acme request whose payload claims globex, and one acme event arriving on day 33. True usage counts every real request once, by the API key that made it. No metering service or payment system is called.
Two questions for every usage event
A usage meter has to decide, for each event, who pays and whether it has already been counted. Tenants’ clients choose their own event ids, so acme and globex both send u-1 and u-2. Acme’s client also retries u-2 once, sends one request (u-9) whose payload claims to be globex, and delivers u-4 on day 33, after the day-30 close. True usage is 5,700 tokens for acme and 2,000 for globex. Deduplication key, Tenant taken from and Usage arriving after the close are the three rules that decide the invoices.
The opening run: globex billed nothing
With the event id alone as the key, acme’s u-1 and u-2 arrive first, so globex’s u-1 (800 tokens) and u-2 (1,200 tokens) are dropped as duplicates. The acme retry is dropped correctly. The tenant comes from the authenticated API key, so u-9 is billed to acme, and the late u-4 is carried to acme’s next invoice. Acme is billed correctly, 5,000 tokens plus 700 carried forward, but globex’s invoice is 0 tokens against 2,000 of real usage. An identity that is unique only within one tenant was treated as global.
Failure boundary: the key and the tenant source
Choose Tenant + event id: globex’s events are kept, the acme retry is still dropped, and both invoices match true usage. Choose No deduplication: the retry is billed twice and acme is over-billed by 2,000 tokens. Keep the correct key and take the tenant from the payload field instead: u-9 is billed to globex, so acme is under-billed by 500 and globex over-billed by 500. A tenant named in the request body is a claim, not an identity; the authenticated key is what the meter should trust.
Late usage
Usage arriving after the close cannot change an invoice that has already been issued. With Carry to the next invoice, acme’s 700-token u-4 appears as a carried-forward line and nothing is lost. With Drop it, acme is under-billed by 700 tokens permanently, even with every other rule correct. Errors combine: with no deduplication and late events dropped, acme is over-billed by 1,300 tokens (2,000 duplicated minus 700 lost), a number that hides both mistakes.
Reading the run and its limits
Play replays the period, each of the eight events with its outcome, both invoices and the result over sixty inspection seconds; Next event, Restart, Speed and Inspection time control the replay, and any input change recomputes it. The table lists every event’s API key, payload tenant, tokens and outcome. Prices and events are fictional; there is no rating engine, currency, tax or invoice adjustment workflow, and a real meter would also bound how long it remembers event keys.