Orb’s founders came from building billing at scale and ran straight into usage-based pain: complex business logic, endless pricing changes, and low-latency alerts on noisy usage streams. This recap distills their talk into an implementation guide you can borrow.
Why Another Billing Platform?
- Usage-first needs: Legacy subscription tools (Chargebee, Recurly, Stripe Billing) break down once pricing depends on metered events instead of monthly seats.
- Engineering lift: Even “simple” seat products kept 5 of 25 engineers busy; infra teams wanted to focus on product, not billing math.
- Data burden: Accurate usage billing needs real-time ingestion, deduplication, and audit-ready aggregation, not CSV uploads. (See the ingestion blueprint for schema choices.)
- Customer UX: Usage plans demand portals, spend graphs, alerts, and commitments/burndown views, not just upgrade/downgrade buttons.
- Change management: Price changes should be versioned, scripted safely, and rolled out without midnight migrations or invoice mismatches.
Domain Building Blocks
- Events: Idempotent usage signals (name, customer id, properties). Schema can evolve; quantity is derived later.
- Metrics: SQL or UI-defined aggregates over events. Multiple metrics can share the same stream. (Cross-link to AI enforcement guide for applying policies on top.)
- Plans: Templates combining usage prices (tied to metrics) and fixed fees (support, seats, platform access). Use immutable versions to avoid “silent repricing.”
- Subscriptions & invoices: Customers inherit plan prices, with per-customer overrides; invoices are draftable and transparent by line item. Link this to the Billing API blueprint if you expose invoices over API.
- Matrix pricing: Price tables over dimensions like region or cluster size to mirror cloud-style SKUs (see latency-aware pricing for a live use case).
Operational Challenges
- Cardinality & scale: Hundreds of thousands of events per second need deduping, windowing, and precise time-range billing. Edge case: backfilled events must post to the original window, not “now.”
- Accounting reality: Revenue is recognized as usage occurs; prepaid commits and off-cycle billing periods complicate ledgers. Pair with the revenue recognition guide.
- Pricing agility: Versioned plans protect audits and make rollouts reversible; overrides keep enterprise contracts consistent. Test changes in staging with historical replays before production.
Low-Latency Alerts, First Cut
Initial design polled alerts in batches: fetch one alert, compute usage from the metric computer, decide to fire, repeat. It worked but wasted work, starved small accounts, and duplicated computation with invoicing. Real failure modes we saw:
- Hot tenants blocked others: A few high-volume accounts consumed the queue; long-tail customers got alerts 30-60 minutes late.
- Double compute: Alerts and invoicing queried the same metric cache separately, doubling load on the event store.
- Point-in-time drift: Alerts fired on partial ingestion, then fired again after backfill, spamming customers.
Event-Driven Alerting Architecture
- Invalidate on events: Every ingested event marks the customer as “needs processing.” No immediate compute; wait for a short window to collapse bursts.
- Schedule future processing: Push customers into a scheduler table with per-account intervals (default few minutes). Frequent senders get consolidated; sparse senders still run quickly.
- Process once per customer: A customer processor recomputes usage, evaluates alerts (usage and cost-based), handles commitments/overages, and issues invoices, sharing one metric computation path.
Results: ~60% alert latency reduction for heavy senders; ~95% reduction for sparse senders; small accounts no longer blocked behind giant tenants.
Alert Design Playbook
- Metric vs. cost alerts: Offer both. Cost alerts mirror draft invoices; metric alerts catch spikes before they become spend.
- Windows that match billing: Align alert windows to plan intervals so customers aren’t confused by mismatched math (see usage API comparison for contract alignment).
- Delivery tiers: Webhook for machines, email/Slack for humans. Rate-limit notifications to avoid alert storms.
- Customer-facing mirrors: Expose the same usage the alert evaluated in portals (e.g., portal upgrades guide) to reduce disputes.
What’s Next
- Push metric computation into the event stream to trim alert latency toward sub-minute.
- Expose the same usage and alert signals to customers via portals and APIs, transparency reduces disputes.
- Tune invalidation windows per tenant to balance latency vs. compute spend; prefer shorter windows for fintech/AI workloads with costly regressions.
- Simulate pricing changes with historical replays (see pricing experiments) before enabling new alerts in production.
If you’re modernizing usage billing, copy the event-to-metric-to-plan stack, keep plans immutable/versioned, and move alerting off polling. Pair this with the Usage API guide and the implementation blueprint to keep meters auditable and customer-facing.