Design a Subscription Billing & Metering System

Commerce, Payments & LedgersMediumdesign-subscription-billing

Design a Subscription Billing & Metering System

Design recurring revenue: metered usage aggregated per customer, plan changes prorated mid-cycle, invoices generated on schedule, and failed payments retried without losing the customer.

Usage MeteringProrationScheduled InvoicingDunning Retries

Traffic & Capacity Estimates:

5M subscribers · 2B usage events/month · invoices generated within a 2-hour window

Functional Requirements

•Meter usage events per customer and aggregate them against plan entitlements.
•Handle upgrades, downgrades, and cancellations mid-cycle with correct proration.
•Generate invoices on each billing anniversary and charge the stored payment method.
•Run a dunning sequence on failure — retry, notify, then downgrade or suspend.

Non-Functional Requirements

•Billing runs must be idempotent — a retried run never double-invoices.
•Usage counts must be exact for billed dimensions, not approximate.
•Invoice generation for the whole book must fit inside its scheduled window.

Back-of-the-Envelope Math

2B usage events/month = ~770/second average, bursty by customer.
5M subscribers on anniversary billing spread over a month = ~170k invoices/day, heavily clustered on the 1st.

Key Architectural Trade-offs

Pre-aggregating usage into hourly rollups makes invoicing fast and makes a late-arriving event a correction entry rather than a recount.
Anniversary billing spreads load and complicates proration; calendar-month billing is simple and concentrates the entire book into one day.
Aggressive dunning retries recover revenue and risk card-network penalties — the retry schedule is a compliance constraint wearing a scheduling costume.

Click or drag a component onto the canvas, then connect the handles to draw the data flow.

3 nodes · 2 edges

Components · 35

Client & Edge4

Compute & Gateway7

Storage & Caching11

Messaging & Streaming6

Coordination & Ops5

Intelligence2

React Flow