Two questions surface in every integration review: is the count still correct after a retry, and where does our data actually go? This deep dive answers both - a metering pipeline built for correctness at 1M+ events/second, and BYOC that runs the same architecture inside your own VPC
Two questions tend to surface back-to-back in any real integration review. The first is about correctness: if an event gets retried, double-counted, or arrives twenty minutes late, does the balance it's supposed to update actually reflect reality, or does the customer see a number that's wrong until someone notices and fixes it manually? The second is about trust boundaries: if this vendor is going to sit in the request path and see every API call, every token, every user action, where does that data actually go, and what happens to enforcement if their cloud has a bad day? Most usage-based billing vendors answer the first question with "eventually consistent, reconciled nightly," and the second with "it goes to our servers, wherever those are." Neither answer works once an AI product is the thing being metered. The moment of truth is the API call itself, and by the time a nightly job catches an error, the damage (fraud, budget overrun, a broken customer relationship) is already done.
Our metering pipeline processes over 1 million events per second, but the throughput number isn't the interesting part. The ingestion-to-enforcement path is. events go from ingested to reflected-in-enforcement in seconds: checkpointed, recoverable, reconcilable, so a retry storm or a network blip doesn't silently duplicate or drop an event. That "seconds, not minutes or hours" gap matters because every credit deduction, every governance decision, and every entitlement check reads from state that metering just wrote. If that write is slow or wrong, everything downstream inherits the error.
Where it sits. Metering runs ahead of the enforcement layer, aggregating raw events (model calls, tokens, agent actions) into the counters that entitlement, credit, and governance checks read from. It's not a side pipe that feeds a monthly report. It's upstream of every real-time decision Stigg makes.
What happens under load. Before an event reaches a counter, it moves through four stages, each one there to prevent a specific failure. First, deduplication: client jitter or a network retry can deliver the same event twice, so Stigg resolves duplicates on an idempotency key before anything is counted. Second, enrichment: the event is tagged with the customer-specific context it needs, such as the organizational hierarchy it belongs to, so usage rolls up to the right entity. Third, dimensional aggregation by model, feature, region, team, or time window, computed as events land, not as a batch job against yesterday's data. Fourth, cost calculation: per-customer credit costs are resolved and fed to the credits engine. If the first stage is wrong, every number downstream inherits the error, which is why dedup comes before aggregation, not after.
This is where the second question gets answered directly, instead of with a compliance PDF. Each core system, Metering, Credits, Governance, Entitlements, deploys independently into your own VPC. Events and usage data don't leave your network to be metered; the same pipeline that runs at scale on our managed cloud runs inside your infrastructure instead.
Latency. No compromise versus managed cloud, the deployment target changes, the sub-10ms P99 decision latency doesn't, because it's the same binaries and the same local-cache architecture, just running where your traffic already is instead of round-tripping to us.
Failure isolation. Because enforcement runs inside your VPC, a problem on our end doesn't take down your enforcement path the way it would if every check had to leave your network. You're no more exposed to our availability than you are to any other workload running in your own environment, because in BYOC that's exactly where enforcement runs.
What you don't have to give up. The modular boundary is real. Each system deploys independently, so you can run Governance in your VPC while leaving Credits on our managed cloud, or split them another way that fits your setup. Deploy what your compliance posture actually requires; keep the rest managed if that's the simpler operational choice.
Durability and compliance. The second question, where the data actually lives, gets a direct answer here too. All usage events stay in your cloud; Stigg never reads raw events, and only the aggregated counters needed for billing sync back. Events are persisted to durable storage before they're acknowledged, so a processing error doesn't lose them, and because raw events are retained in their original format, you can rebuild usage totals from scratch or reprocess them if aggregation logic changes. Older events tier to cold storage in your own object store, under your retention policy and encrypted with your own KMS keys.
"It's fast" and "it's compliant" are usually two different vendor conversations that end in two different compromises. Here they're the same architecture, deployed differently depending on where your data needs to live.
.png)
.png)
