7. Implementation Approach
Bucket 1 (Real-Time Enforcement & Scale) is the capability this approach covers, through two gaps: UBB-2 (high-volume event ingestion and exact rating) and UBB-1 (real-time enforcement and a hard stop). Chargebee builds both natively, as a layer beside its existing batch billing and not as a rewrite. Chargebee already owns the plans, allowances and balances that enforcement depends on, so a native build avoids a second source of truth. UBB-2 is built first because it is the foundation: UBB-1 reads from it, and UBB-1's next steps are decided from what UBB-2 shows.
UBB-2 comes first. It produces the running usage totals, the event stream and the observability that UBB-1 needs. UBB-1 is not designed in isolation: once UBB-2 is live with a pilot customer, the team reviews what it shows (below) and uses those readings to decide how UBB-1 should be built and in what order.
Part A · UBB-2: high-volume event pipeline (built first)
Modelled on how Metronome's documented pipeline works (events, billable metrics, rating, running balances), adapted to Chargebee's plans and invoicing.
Running totals feed
Usage and alerts API
Customer-visible usage and threshold alerts (first customer value)
UBB-1 balance service
Reads running totals to decide allow or deny
Existing invoicing
Exact totals at period close feed the current invoice flow
1. Ingest API
Authenticated, batched endpoint for usage events. Each event carries a unique transaction ID (the idempotency key), a customer, an event type, a timestamp and flexible properties. Acknowledges quickly and processes asynchronously. Accepts an alias for the customer so senders don't need Chargebee IDs.
2. Durable event stream
Events are partitioned by customer, delivered at least once and de-duplicated on the transaction ID, so the effect is exactly-once. Supports backpressure and replay, with a long dedup window so events can be re-sent after an incident without double-charging.
3. Meters (billable metrics)
Filter and aggregate events into quantities: count, sum, max, unique count, latest. One event can feed several meters. Meters follow the subscription's billing period.
4. Rating
Applies Chargebee's existing pricing models (flat, per-unit, tiered, volume, stair-step) to metered quantities, with exact decimal precision for sub-cent prices, custom units (credits, tokens) with conversion, and plan-scoped allowances.
5. Running-totals store
Current usage per customer, meter and period, available through a read API. This is what UBB-1 reads from.
6. Late events and corrections
A defined window for backdated events, with the ability to correct or remove bad usage (addresses CB-9).
7. Replay and backfill
Raw events are retained so meters can be re-aggregated after a definition changes. Metronome's metrics are not retroactive, so this is a deliberate improvement.
8. Observability
Event search, ingest lag, rejected-event counts and completeness measures, so customers can trust the pipeline and the team can read how it behaves.
Gate · What UBB-2 tells UBB-1
Before UBB-1 is built, the team reviews these readings from the UBB-2 pilot. Each one settles a specific UBB-1 decision.
| What UBB-2 shows | UBB-1 decision it informs |
|---|---|
| How fresh the running totals are (delay from event sent to total updated) | Whether the balance service can read running totals directly, or needs holds and local leases to stay ahead of the delay. |
| Late and duplicate event rates | How much overshoot to allow, the default for failing open or closed, and how large a hold should be. |
| Gap between running totals and the exact final rating | The reconciliation method, and how much drift a hard stop can tolerate. |
| Burst and spike profile of real customer usage | Default thresholds (for example alert, throttle and block levels), hold sizes, and whether to throttle or block. |
| Who actually sends events (app, gateway, provider logs) and how clean they are | Which entry tier to build first (gateway or connector versus SDK), and whether apps need to estimate usage at all. |
| Which meters and plans customers want limits on | Which balances and limits UBB-1 enforces first. |
| Event volume by segment | Whether Segment 1-style holds are enough, or leases and local counters are needed for Segments 3 and 7. |
Part B · UBB-1: real-time enforcement (built on UBB-2)
One transaction, end to end. The balance is built from the UBB-2 running totals.
App calls Reserve
Before running a metered action (e.g. an inference call), the customer's app calls Reserve on the Real-Time Balance Service, passing an estimated usage amount.
Check the balance
The service checks a fast balance built from the UBB-2 running totals, not the batch-rated ledger, which is too slow for this path.
Approve or deny
If the balance covers the reserve, the service holds the amount and returns Approved. If not, it returns Denied and the app blocks the action before it runs. This is the hard stop UBB-1 delivers.
App proceeds
The app only runs the metered action after receiving Approved.
App calls Confirm
Once the action completes, the app calls Confirm with the actual consumed amount (which may differ from the estimate), and the service settles the hold.
Events feed the UBB-2 stream
The usage event goes to the UBB-2 event stream, which updates the running totals the balance reads, and feeds the existing rating pipeline that still generates the invoice at period close.
Stages
Stage 1 · UBB-2 foundation
- Ingest API, event stream with dedup and replay, meters, rating, running totals
- Event search and observability
- Usage visibility and threshold alerts for the pilot customer (the first customer-visible value)
Gate · Review UBB-2 readings
- The team reviews the readings above from the pilot and decides how UBB-1 is built and in what order
Stage 2 · UBB-1 crawl
- Reserve, Confirm and Release, with shadow mode (log would-have-blocked) and thresholds
- One pilot customer, balance read from running totals
Stage 3 · UBB-1 walk
- Live balance API, hosted out-of-credits and top-up page, auto-recharge, webhooks
- Gateway and connector entry point for a hard stop without code changes
Stage 4 · Run and scale
- Higher-volume rating, leases and local counters, multi-region, a latency commitment
- Consumption insights (runaway detection, burn-rate forecasts), and Segment 3 and 7 volumes
Plug-and-play entry points
Tier 0
Connect, run in shadow mode and get alerts and webhooks. No enforcement, no code change beyond sending events.
Tier 1
A gateway or connector for AI gateways and SDKs the customer already uses. Gives a hard stop with a base-URL change and no application code.
Tier 2
SDK and API (Reserve, Confirm, Release) for custom flows and non-HTTP workloads.
Open decisions
- Extend Chargebee's current usage handling or run a new pipeline beside it (the recommendation is a new pipeline for high-volume customers, and the existing path for low-volume ones).
- The scale target. Metronome's published figure of about 100,000 events per second is the first benchmark; Orb has reported higher figures from secondary sources.
- How long raw events are retained, which drives replay, backfill and storage cost.
- Fail open or fail closed by default, and whether that differs by segment.
- How apps estimate usage before a call, since the estimate sets the hold.
- Whether a gateway sees prompts: meter from counts only, retain no payloads, or offer a self-hosted option.
- Who owns the denied-state experience: Chargebee's hosted page or the vendor's own UI.
Risks
- Customer value arrives later if enforcement waits behind the pipeline. Mitigation: ship usage visibility and alerts in Stage 1.
- Correctness at volume (rounding, duplicates, late events) is harder than raw throughput.
- Adoption friction on the customer side. Mitigation: the entry tiers.
- Drift between the fast balance and the exact ledger. Mitigation: reconciliation, and the readings from the gate.
- Chargebee in the request path adds latency and uptime obligations a batch billing system never had.
- Chargebee's real architecture has not been reviewed; engineering must confirm feasibility.