Usage Metering & Billing Pipeline · View 14 of 22 · Runtime
Decisions
- One pipeline with five aggregate functions, selected by the meter's type field. A new meter is a configuration row choosing a lane, which is what lets packaging change without a deployment — and is the direct consequence of the pricing manager's goal in view 03.
- Gauges are time-weighted rather than last-value, because a customer who ran 400 seats for one hour and 40 for the rest of the month should not be billed for 400.
- The dimensioned lane shows where cardinality enters: a region-dimensioned rate card is cheap, a request-id-dimensioned one is ruinous.
Assumptions
- 400 meters in total across the five types (stated assumption), with counters the large majority.
- Unique-entity meters close monthly only; a daily distinct count at this volume is not affordable and nothing prices against it.
Risks
- Unique-entity counting is not incrementally cheap and its state grows with the period. It is the one lane that could justify an approximate counter, at the cost of a figure that cannot be reproduced exactly — which this architecture otherwise refuses.
- A meter whose type is changed after usage has been metered under the old one is a restatement, not an edit. Nothing in the model stops someone trying.