When late is wrong: Charging at real scale

I spent the best part of a decade building online charging systems before I joined Volt, and I'll let you in on something: in a small market, charging is a solved problem. Ireland has a few million subscribers and you can drive across it in four hours. One central system, tight SLAs, shared family balances, all handled without anyone breaking a sweat.

Then you try to do the same thing for a US operator, or a pan-European group, and two things break at once. The subscriber base won't fit in one node, and the geography won't fit inside the latency budget. A round trip from one coast of the US to the other is sixty-odd milliseconds before you've done any actual work, which is most of a 5G charging SLA gone. So you distribute, and the moment you distribute, the same shared balance is being hit from more than one place at the same time. Consistency stops being free.

And here's the bit that should keep CFOs awake. When the answer arrives late, the network doesn't wait. Most operators configure their failure handling to continue service rather than block a paying customer, which is the right call, but it means a missed SLA doesn't show up as an alarm. It shows up as revenue you've already agreed to give away. In charging, late is not a softer version of wrong. It can be worse: a wrong decision is usually a one-off you can catch and reconcile, while late decisions arrive by the thousand at the busiest moment of the day, every one of them pre-approved to cost you money.

The TPS pitfall

This is why I've grown allergic to headline throughput numbers. Every vendor has a big TPS figure. Almost none of them tell you the K-factor, whether durability was switched on, what the 99th percentile latency looked like while they were hitting it, or what a "transaction" actually was. A single-row lookup and a stored procedure that deduplicates, enriches, aggregates and updates three materialised views are both one transaction, and only one of them is charging. A million of the first kind with no replication and a p99 you'd rather not discuss isn't a charging system, it's a demo.

Adam Majcher's recently published benchmark report, How Fast Is VoltDB in Reality?, is refreshing precisely because it refuses to play that game. The mediation workload, with deduplication, enrichment and aggregation against a subscriber table of over five million rows, ran at around 240,000 transactions per second with 99th percentile latency under five milliseconds. That's with K=1 and command logging switched on, in other words the configuration you'd actually go live with, not the one you'd take to a trade show. The charging workload peaked at 3.2 million transactions per second without replication and still held around 3,500 transactions per second per vCPU with the K=1 replicas counted in, p99 under five milliseconds either way. Adam even tells you what redundancy costs: roughly half your per-core throughput. Every one of those transactions is fully ACID, every one of them against current state.

What that buys you

The architecture behind those numbers matters more than the numbers themselves. State, decision logic and the recording of the outcome live in one execution and consistency model, so a quota grant never argues with the usage event that follows it. Partitions carry K-safe replicas, so a node going out for an upgrade costs you a bit of redundancy for a few minutes, not latency and not correctness. And replication between sites is active-everywhere, so each site answers its own traffic at local latency and nobody has to make the coast-to-coast round trip inside the SLA.

Who should care

If you're an in-house engineering team at a CSP that builds its own platforms, a BSS vendor whose charging, policy or mediation product has to hold up at group scale, or an OSS team trying to get network automation to close the loop before subscribers notice, we've written an Architecture Guide that sets all of this out vendor-neutrally, with the Volt-specific bit clearly fenced off at the end. It covers the on-line versus event-driven split, where ML and agentic AI genuinely belong (and where they don't), and the operational requirements everyone forgets until the first maintenance window. The event-driven side is covered too: the guide's network automation section, and the autonomous-network scenario in Adam's report, running ML inference inline on telemetry from five million endpoints. Read it, then read Adam's report, then kick the tyres yourself on the Developer Hub. Because sooner or later, everyone's subscriber base gets big enough for the physics to matter.