Aerospike RF2 self-healing vs. Redis Cluster failover: What happens after the node dies

Modern distributed databases are designed to keep applications running even when individual components fail. Data is typically replicated across multiple nodes, so a surviving copy can continue serving requests while the system detects the failure and adjusts the cluster around it.

But keeping an application online is only the first stage of recovery. Once a node disappears, the cluster operates with reduced redundancy: data ownership and placement need adjustment, missing replicas need rebuilding, and the system must continue handling new writes while that work is underway. How that degraded period is managed affects both durability and the system's exposure to a second failure.

Aerospike and Redis take different approaches to this problem. Aerospike's replication factor 2 (RF2) model builds replication and data placement into the cluster's own operating logic, while Redis uses a primary/replica architecture in which replica promotion and, when an application requests it, per-write replication acknowledgment carry the load instead. The differences become clearer once you look past the initial failover and focus on what happens during the cluster's recovery.

What the benchmark covers

A benchmark conducted by McKnight Consulting Group compared Redis and Aerospike using a uniformly distributed 90/10 read/update workload, with Aerospike configured at RF2 and Redis Cluster configured with one replica per primary. Both systems were tested under sustained, normal operating conditions with healthy, available clusters.

The benchmark did not include a node failure, so it does not provide measured results for failure detection, failover, replica promotion, or time to restore redundancy. Any discussion of recovery behavior therefore describes the documented design of each architecture rather than observed failure and recovery behavior from the benchmark.

Aerospike RF2: Redundancy as part of the cluster model

Aerospike's approach starts with RF2: every record has two copies distributed across the cluster, which was the configuration used in the benchmark. The second copy provides continued availability when a node disappears. Replication is integrated into the cluster’s operating architecture, with the database managing it alongside data placement and balancing.

Immediate availability and complete recovery are separate stages. When a node fails, the surviving replica can serve the affected data immediately, while restoring redundancy requires the cluster to detect the membership change, redistribute ownership, move data, and rebuild the missing copy. This recovery work consumes network bandwidth, CPU, storage I/O, and replication capacity. Aerospike handles these steps automatically, so administrators do not need to manually reconstruct partition ownership or determine where the missing data should be placed. Node failure and recovery are therefore handled as part of normal cluster behavior rather than as a separate operational procedure.

RF2 is not RF3

Two copies are still only two copies. If an RF2 cluster loses one node, one copy of the affected data remains. If a second failure destroys that remaining copy before the cluster restores redundancy, no third copy exists to fall back on.

The exact outcome depends on which nodes fail and how replicas are distributed, but the underlying principle holds across databases: RF2 doesn't provide the same failure margin as RF3. A Redis deployment configured with two replicas per primary, three total copies, has the same basic margin as an RF2 deployment, and roughly the same as an Aerospike RF3 configuration. The replication factor, not the database vendor, determines this aspect of failure tolerance.

The benchmark illustrates why the distinction matters here specifically: Aerospike ran at RF2, and Redis Cluster was configured with --cluster-replicas 1, giving each primary one replica. Both systems, therefore, had two copies of their data in the tested configuration; neither had the additional margin RF3 provides. In cloud environments, a failed compute node may not return with its original local state. As a result, an Aerospike or Redis RF2 deployment should not be considered equivalent to RF3 in terms of multi-node failure resilience simply because both configurations can remain available after a single-node failure.

This is the rationale behind Aerospike’s “High availability at two copies, not three” differentiator. The claim is not that two copies provide greater failure tolerance than three. Rather, Aerospike is positioned as meeting the required availability threshold at RF2, where some alternatives require RF3. The distinction is primarily economic, reflecting the infrastructure cost of maintaining additional copies rather than a claim of superior failure resilience.

Availability zones change the equation

The same principle applies at the availability-zone level. An RF2 deployment can survive the loss of an entire AZ when its two copies are placed in separate failure domains, so replica placement and physical topology are critical to the outcome. The benchmark does not evaluate this scenario because all four server nodes ran within a single AWS availability zone. It therefore provides no basis for assessing either database’s resilience to an AZ failure. In a multi-AZ deployment, the relevant considerations are replica placement, the capacity that remains after a failure, and the time required to provision replacement infrastructure.

Redis: Failover and infrastructure recovery

Redis is worth describing precisely rather than just labeling it "failover-oriented." At the database level, open-source Redis Cluster  (the version tested in the benchmark) uses a primary/replica model: data is divided into hash slots, primaries own those slots, and replicas provide redundancy. When a primary fails, the cluster detects it through its gossip mechanism; the remaining primaries vote, and a replica can be promoted to take over the affected slots. Clients then learn about the topology change through the Redis Cluster protocol, including MOVED and ASK redirects.

Redis Cloud adds another layer of automation, untested in this benchmark: single-zone replication where a replica takes over on primary failure, and multi-zone configurations that place primary and replica data in different availability zones. It also typically runs a proxy layer that hides the hash-slot topology from clients, producing a different failover experience than a self-managed Redis Cluster, where clients participate directly in handling topology changes.

The operational picture matters as well. In the benchmark environment, Redis ran as 32 separate processes per node, 128 processes across the four-node cluster, each needing individual deployment and monitoring. Self-managed Redis also doesn't guarantee that a record's two replicas land on different physical machines; placement must be managed deliberately to avoid both copies ending up on the same box. Redis Enterprise and managed Redis services automate much of this. But the architectural distinction underneath remains: Redis OSS assembles its replication topology from independently managed processes, while Aerospike treats replication and placement as properties of the cluster itself, which matters most for write durability during a degraded state.

The difference in the degraded state

When an Aerospike RF2 cluster loses a node, the surviving replica remains available, leaving some records temporarily with one copy instead of two – degraded, but the replication model itself still governs recovery and automatically restores the missing redundancy. Redis, by contrast, replicates asynchronously by default: a primary can acknowledge a write before any replica has. The benchmark reflects this difference directly: Redis used its default asynchronous acknowledgment, while Aerospike acknowledged writes only after replica confirmation, a durability difference that exists entirely independent of node-failure mechanics. Applications that need a stronger guarantee in Redis can reach for the WAIT command.

Redis WAIT: replication as a client-side request

WAIT lets an application ask Redis to block until a specified number of replicas have acknowledged prior writes, or until a timeout expires:

SET customer:123 status "paid"
WAIT 1 1000

This asks Redis to wait up to one second for at least one replica to acknowledge the write. Redis returns however many replicas actually acknowledged it; if fewer than requested, the command still returns once the timeout hits, and the application has to decide whether the returned count meets its bar.

The gap becomes clear once a replica is missing. If a primary's only replica has failed, ordinary asynchronous writes still go through fine, but WAIT 1 1000 has nothing to satisfy: no replica is available, so the command blocks until the timeout and returns 0. The application then has to decide what to do — reject the write, retry it, accept it without the requested durability, wait for replacement infrastructure, or reconcile later. Redis itself makes it explicit that WAIT doesn't make it a strongly consistent store, and that even synchronously replicated writes can be lost during a failover; it's a per-write client request, not a standing replication guarantee that the database enforces on its own.

Aerospike handles the same degraded state differently: with RF2, the replication model remains part of the database's operating behavior, and the cluster automatically restores the missing redundancy rather than leaving that decision to the application on a per-write basis. That said, WAIT addresses a real requirement and makes an application's durability preference explicit — the distinction is that replication factor and per-write acknowledgment are different kinds of guarantees, and that difference matters most exactly when a cluster is missing one of its replicas.

Side by side

The failure-margin difference between RF2 and RF3 applies to either database and depends entirely on how replication is configured, a function of replication factor, not an inherent difference between the two systems. Neither configuration in this benchmark was tested against an actual node failure; the table above describes documented architecture, not observed recovery.

The costs of recovery

Cluster recovery consumes resources regardless of the database: network bandwidth, CPU, disk I/O, replication capacity, cluster management overhead, and more. Recovering quickly shortens how long the system is exposed to a second failure, but aggressive recovery can also compete with application traffic for those same resources.

The benchmark does provide real, measured context for one closely related question: how Aerospike's storage-backed architecture holds up under sustained load, even without a failure event. With Aerospike's page cache disabled, reads were served entirely from disk; throughput was lower than the in-memory configuration, but latency stayed remarkably stable. Reported p99.99 latency jitter (the standard deviation of that percentile over the run) stayed between 0.10 and 0.26 ms in that configuration, against 8.53 ms for Redis's p99.99 jitter at its highest in-memory load; this result held even as the dataset grew tenfold, from 500 million to 5 billion records, on the same four-node cluster. 

This is the basis for Aerospike’s “Cache speed, disk economics and predictable performance, regardless of conditions” differentiator. The focus is on maintaining predictable performance as data grows beyond what can fit in memory, which is particularly relevant to architectures that must continue serving requests while also moving data during rebalancing. The benchmark does not measure failover performance, however, and it does not provide any data on Redis failover timing.

Choosing between the architectures

The choice here turns more on how the surrounding system needs to behave before, during, and after a failure than on which database can technically survive one. Aerospike's model places replication, placement, and redistribution largely within the database itself. This is particularly useful for large, disk-resident datasets, where persistent storage is a first-class part of the architecture rather than an afterthought bolted onto an in-memory design. Redis offers a different tradeoff: applications can work directly with its primary/replica model and reach for WAIT when they need an explicit, stronger per-write guarantee, and managed Redis services can absorb much of the operational burden of placement, failover, and multi-zone deployment (none of which this particular benchmark exercised, since it tested self-managed, open-source Redis in a single AWS availability zone).

The comparison that actually matters is between configurations and failure requirements, not database names. Replication factor, replica placement, write acknowledgment, storage architecture, and the specific failure scenarios a deployment has to survive all shape the real answer; an RF2 deployment and a three-copy Redis deployment can offer very different protection against a second failure than what was tested here, independent of which technology is underneath.

The real difference is in recovery

A node failure is only the beginning of a recovery event. The more consequential period comes afterward, when the cluster is still serving traffic with fewer copies of some data than it was designed to hold. Aerospike RF2 and Redis can both keep an application running through a single-node failure, but they take different approaches to what happens next. Aerospike treats replication and placement as properties of the cluster itself, automatically restoring missing redundancy. Redis separates replica promotion from write-level replication guarantees, giving applications explicit control through mechanisms like WAIT.

Neither approach removes the underlying trade-offs: RF2 still provides less protection against a second failure than RF3, rebuilding still consumes resources, and this benchmark doesn't establish how either system performs during an actual failure. The practical question isn't simply whether a database can fail over, but how much of the recovery process is built into the database's own operating model, versus how much responsibility stays with the application and the infrastructure around it. Replication factor, replica placement, write semantics, and the specific failure scenarios a deployment has to withstand matter more here than the database name alone.