I’ve had some version of the same conversation dozens of times. An operator or platform team has invested heavily in an AI-driven decisioning system (fraud detection, network policy, real-time charging), and the models are genuinely good. Then they hit production at scale, and something breaks. Not the model. The infrastructure underneath it.
The assumption that keeps causing this is that high availability is something you configure after the architecture is decided. Add nodes. Enable replication. You’re done. In stateless systems, that’s roughly true. In strongly consistent, stateful systems, the kind that real-time AI decisioning actually requires, it isn’t even close.
Stateless vs. stateful: why the same rules don’t apply
In a stateless service, redundancy simply compounds. Each node you add increases your uptime probability, and the math works in your favour. However, strongly consistent stateful systems work in reverse. When every node must participate in consistent transactions, each additional machine introduces a new failure surface. Scale up without accounting for this, and your expected uptime doesn’t improve; it deteriorates.
This is the number that surprises most infrastructure architects when they first work through it. A 5-node cluster in a strongly consistent stateful system with 90% machine uptime has a baseline system uptime of around 59%. That’s not a typo. Without deliberate replication and partitioning design, scaling out actively works against you.
For telecom operators, the consequences are significantly greater than an incorrect metric on a dashboard. For example, an inconsistent partition state in a fraud decisioning engine doesn’t simply produce. It can suspend a valid enterprise account, misroute a 5G session, or double-charge a subscriber at scale. And all before anyone can intervene.
The consistency trade-off that isn’t really a trade-off
It is tempting to relax consistency to recover availability headroom. This is a common architectural choice, and for certain workloads it’s the right one. But in use cases where AI is asked to take autonomous, consequential action (suspending accounts, enforcing network policy, triggering billing events), it isn’t a trade-off. It’s a risk transfer.
You move the problem from the data layer into operations and compliance, where it’s far more expensive and far less visible until something goes wrong. The architectural goal has to be to achieve high availability within strong-consistency constraints, not by weakening them.
That requires specific design decisions made upfront, such as partitioning with single-threaded execution per partition to eliminate resource contention, replication strategies that use deterministic transaction execution rather than synchronous commit overhead to keep copies consistent, and node pairing topologies that maximise failure tolerance for a given cluster size without compounding the availability problem.
The geo-redundancy maths most teams get wrong
Single-data-center redundancy is table stakes. The harder problem to solve is what happens when you lose an availability zone or need to architect entirely across regions.
The number that teams consistently underestimate is that a service with two-nines uptime, deployed in an availability zone with two-nines uptime, gives you roughly one nine of combined availability. And the probabilities compound; they don’t simply add. This changes the architecture conversation significantly. Meeting a 99.99% SLA commitment at the service level requires understanding exactly how machine uptime, cluster uptime, zone uptime, and region uptime interact and designing the replication topology accordingly, rather than retrofitting it.
Multi-region is a different problem again. Inter-region latency rules out synchronous replication, which means consistency guarantees change, and conflict detection and resolution become load-bearing rather than optional. That’s a design constraint that has to be accommodated from the start.
Why this matters specifically for AI decisioning
The reason I think about HA architecture through an AI lens now, rather than purely as an infrastructure question, is that the stakes of getting it wrong have changed.
When an AI model makes a recommendation, the system that acts on it needs to do so based on the current, consistent, authoritative state, at the exact moment the action fires. If the data layer is operating with degraded availability, stale reads, or partition inconsistencies under load, the AI output is only as trustworthy as the underlying infrastructure. The model accuracy becomes largely irrelevant.
This is the gap that catches teams out. They’ve done the work on the model, but they haven’t done the work to determine whether the decisioning layer can guarantee a consistent state at execution time, across failure scenarios, at the throughput the use case demands.
High availability in strongly consistent systems isn’t a standalone infrastructure concern. It’s the precondition for AI automation that can actually be trusted to act without a human review gate on every consequential decision.
If the failure modes and geo-redundancy patterns described here map to challenges you’re currently navigating, or will be as transaction volumes and SLA obligations grow, I’m happy to discuss. Reach the Volt team at [email protected] or download the full technical paper.
Originally Posted At : High Availability in Strongly Consistent Systems Is an Architecture Decision, Not a Feature.
Sign in to leave a comment.