Design a “Usage-based Billing” Analytics System

Medium45 min
1 / 30
understanding•10 min read

Problem Statement: Metering Money in Motion

Frames usage-based billing as an accuracy-first data system, not a dashboard with an invoice attached.

Problem statement

Design a usage-based billing analytics system for a multi-tenant platform (API product, observability vendor, infrastructure service — the shape is the same). Every tenant generates meterable events: API calls, CPU-seconds, ingested log lines, compute-hours, messages sent. The platform must (1) ingest those events continuously at high concurrency, (2) attribute each event to the correct tenant and price plan, (3) aggregate usage into counters that customers can watch in near real time, (4) compute cost per billing cycle using plan pricing, tiers, discounts and thresholds, (5) emit an accurate, immutable invoice at cycle close, and (6) alert when usage crosses budgets or plan thresholds.

This is not an analytics dashboard problem that happens to bill people. It is a financial ledger problem driven by a high-rate event stream. The defining tension: the telemetry path wants speed, approximate freshness, and cheap retries; the money path wants exactness, auditability, and determinism. A lost dashboard sample annoys a user; a lost usage event either underbills (revenue leakage) or, after a correction, produces a surprise charge (dispute and churn). Billing trust is the product.

Why this question is distinctive

Most big-data interview questions tolerate eventual consistency everywhere. Usage billing does not. The system must answer, months later and under audit, exactly why invoice INV-2026-07-118342 charged tenant T-411 $8,314.22: which raw events, which deduplication decision, which plan version, which rating rule, which restatement. That reconstructability requirement shapes everything — event envelopes carry plan and schema versions, aggregations are recomputable from raw data, and invoice finalization is a signed, append-only transition.

The brief requires real-time or batch ingestion, mapping to the correct tenant and plan, summation and cost computation, invoicing at cycle end, accuracy that avoids disputes, high concurrency across many customers, scalability in data volume, and threshold-based alerts for sudden spikes. Every one of those is designed for explicitly in the sections that follow.

The four planes

  1. Metering plane: ingestion, identity, deduplication, per-tenant counters, budget alerts. Optimizes for accuracy and bounded latency; at-least-once transport with application-level idempotency.
  2. Rating plane: plan catalog, plan versions, tier and proration logic, cycle aggregation, invoice computation. Deterministic and replayable; the same raw events plus the same plan version must always produce the same invoice.
  3. Ledger plane: double-entry postings, invoice finalization, revenue recognition, disputes, credits, restatements. Immutable, audited, strongly consistent.
  4. Learning plane: cost analytics, anomaly detection, forecasting, plan-economics reporting. Reads projections and compacted archives; never writes back into the money path.

Strong answers keep these planes separate. The metering plane may degrade (stale dashboards) without weakening the ledger plane, and the learning plane may lag a day without touching invoice correctness.

Public operating baseline versus design assumptions

The category is operationally real and large. Stripe reports it processed over $1 trillion in payments in 2023, and its Billing product supports metered usage via usage-record APIs with idempotency keys documented in its public API reference. Datadog, a company whose entire pricing is usage-based (host-hours, log GB ingested, custom metrics), reported more than 28,000 customers in its 2023 filings. Twilio built a multi-billion-dollar business on metered per-unit pricing and reports more than 300,000 active customer accounts. Snowflake bills per-second of compute; Google BigQuery bills per bytes scanned. These are cited public figures and pricing facts, used as context — not as our design targets.

For capacity planning this answer assumes a fictional mature platform with 50,000 paying tenants, 8,000 actively emitting at any moment, 175 million usage events per day (about 2,000 events per second average), and provisioned peak of 20,000 events per second. Unless a number is tied to a citation, it is a stated design assumption.

Key Highlights

  • •The telemetry path optimizes speed; the money path optimizes exactness — separating these two planes is the entire architecture.
  • •Every charge must be reconstructable months later: raw events, dedup decisions, plan version, rating rule, and restatements.
  • •Public figures (Stripe >$1T processed in 2023, Datadog 28,000+ customers, Twilio 300,000+ accounts) provide context; all uncited numbers here are explicit assumptions.
  • •Four planes: metering, rating, ledger, learning. Learning never writes back into the money path.
  • •A stale usage dashboard is a degradation; an inaccurate invoice is a product failure.
Lead With the Ledger, Not the Stream
State in the first two minutes that this is an accuracy-first financial system fed by a stream, not a streaming dashboard that sometimes bills. That instantly reframes every later decision around determinism and auditability.
Do Not Draw a Dashboard With Invoices
A design where invoice totals come from a lossy, approximated real-time counter — with no recompute path from raw events — fails the dispute and audit requirement and will not survive a serious interview.

Section Rescue Kit

Buzzwords to use:

Meter-to-CashReconstructability

Safe statements:

  • "I will separate usage visibility from money movement: the first may be stale, the second must be exact."
  • "Before choosing stores, let me define which decisions are speed-tolerant and which are accuracy-critical."
Design a “Usage-based Billing” Analytics System - System Design | WinJob | WinJob