Following money through a subscription product: usage measurement, payment-provider events, plan entitlements, proration, and failed payments.
Each step between a customer using your product and the money arriving has a failure mode that quietly loses revenue or overcharges someone: usage counted twice or not at all, subscription events applied out of order, stale permissions, rounding that does not add up, and payment failures handled inconsistently. Most guides in this section include a lab that measures one of those failures, so you can check your own system against the same scenario.
Count usage so that retries and late events are neither lost nor billed twice.
Lab finding: Redis marker first: 2,018 lost, 191 double-billed. Marker cleared on error: 92 lost, 196 double-billed. Unique key in the ledger: exactly 200,000.
Keep subscription state correct when provider events arrive late, twice, or out of order.
Lab finding: Arrival order: 30.5%. created guard with a NULL start: 100%. created guard otherwise: about 14%. Fetching the current object: 0%.
Turn plans into feature and quota checks without serving stale permissions.
Lab finding: Messages only: up to 58 minutes. With a 60 s cache lifetime: 38 s. With a 5 s version poll: 1.6 s.
Charge the right amount when a customer changes plans in the middle of a period.
Lab finding: 30-day months: +$4.76 in February, -$2.16 in 31-day months. Rounding order: 1 cent. A 365-day year overcharged a leap-year true-up by $16.44.
Handle failed payments with a versioned policy that duplicate events cannot confuse.
Put numbers on it: Tenant Unit Economics Calculator
Move plan checks into data, cache them safely, and enforce seat limits where they cannot be exceeded. A lab shows how long one lost invalidation message keeps a server wrong.
Which declines to retry, how to limit access while a payment is overdue, what to tell customers, and a tested Go state machine that handles duplicate payment events.
Design a metering pipeline from event to invoice, and see a lab in which the popular 'set a Redis marker first' pattern lost about 1% of billable usage.
Proration is simple arithmetic plus policy. A lab computes one upgrade for every 2026 month and shows where 30-day and 365-day shortcuts change the invoice.
Stripe may deliver events late, twice, or out of order. A lab replays 40,000 events through five handlers; only fetching the current object kept every subscription correct.
