Choosing Aerospike Strong Consistency: When Linearizability Matters and What It Costs

The problem: you need linearizable writes but your cluster spans availability zones

Your application decrements inventory counters on every order. Two concurrent requests for the last item must not both succeed. Aerospike's default AP (eventual-consistency) mode resolves conflicts with last-write-wins, which can oversell. The strong-consistency (SC) namespace promises linearizable single-record operations — but it changes failure behavior, disables features, and adds latency. This post walks through the trade-offs so you can decide whether SC fits your workload.

How SC works: Raft per partition

SC namespaces run a Raft consensus group for each partition. A write must be acknowledged by a quorum of replicas before the client receives success. With the default replication-factor of 2, that means 2/2 replicas; with RF=3, 2/3. The partition leader coordinates the log replication. Reads default to linearizable consistency level: they contact the quorum and verify the leader's lease, guaranteeing the latest committed value.

Key terms:

• Quorum: minimum replica set that must acknowledge (⌈(RF+1)/2⌉).
• Leader lease: time-bound authority granted to the Raft leader; prevents split-brain during network instability.
• Linearizable: every operation appears to execute atomically at some point between its invocation and completion.

Configuration constraints you cannot change later

SC is a namespace-level property set at creation time. You cannot flip an existing AP namespace to SC. The namespace must have replication-factor ≥ 2 and strong-consistency true. Once created, the following features are disabled:

• XDR (cross-datacenter replication)
• Secondary indexes on non-primary-key bins
• Certain UDF write patterns that conflict with consensus ordering

If your architecture relies on XDR for active-active multi-region or on secondary indexes for query flexibility, SC is not a drop-in replacement.

Read consistency levels: linearizable vs. allow-replica

SC reads default to linearizable. You can relax to allow-replica for lower latency — the read goes to any replica without quorum verification — but you lose linearizability and may see stale data. Do not use allow-replica for operations requiring strict ordering (financial balances, inventory decrements). The consistency level is set per operation in the client policy.

Failure behavior: minority partition becomes unavailable

During a network partition, the Raft majority continues to accept writes and linearizable reads. The minority partition rejects writes and linearizable reads with AEROSPIKE_ERR_CLUSTER_CHANGE. This contrasts with AP mode, where both sides accept writes and resolve conflicts later. Your application must handle unavailability: retry with exponential backoff, circuit breakers, and idempotent operations (use generation or check-and-set).

Worked example: create SC namespace, benchmark, simulate partition

1. Create the namespace (run on any seed node as admin)

asinfo -v "set-config:context=namespace;id=inventory-sc;strong-consistency=true;replication-factor=3;memory-size=4G;storage-engine=device{file=/opt/aerospike/data/inventory.dat,filesize=16G}"

Requires admin privileges. Verify with asinfo -v 'namespace/inventory-sc' and confirm strong_consistency=true.

2. Benchmark write throughput (run from client machine with network access to cluster)

asbench -h <seed-node> -n inventory-sc -w W,100 -z 1000000 --latency

Compare with an identical AP namespace on the same hardware. Expect ~30-50% write throughput reduction and 1-2 extra network round-trips for quorum. Measure transactions/sec and p99 latency.

3. Simulate a network partition (run on one node as root)

tc qdisc add dev eth0 root netem loss 100%

This isolates the node. From a client, attempt a write to the SC namespace — you should receive AEROSPIKE_ERR_CLUSTER_CHANGE. The majority partition (the other two nodes) continues to serve writes. Remove the rule with tc qdisc del dev eth0 root to heal. Check server logs for raft and strong-consistency keywords; correlate with asinfo -v 'statistics' | grep raft_leader_changes.

Trade-offs and limitations

Dimension	AP mode	SC mode
Consistency	Eventual (last-write-wins or CRDT)	Linearizable single-record
Write latency	1 RTT to replica	1-2 extra RTTs for quorum
Write throughput	Baseline	~30-50% lower
Partition tolerance	Both sides accept writes	Minority unavailable
XDR	Supported	Disabled
Secondary indexes	Supported	Unsupported (7.x)
Rolling upgrades	Standard	Upgrade non-leaders first

Capacity planning must account for quorum write amplification: provision 2-3x the SSD IOPS and network bandwidth versus AP mode. Frequent leader elections (watch raft_leader_changes) indicate network instability that degrades both performance and availability.

Actionable closing: decision checklist

1. Require linearizability? If yes, SC is the only built-in option. If eventual consistency with application-level conflict resolution works, stay with AP.
2. Can you tolerate unavailability during partitions? SC minority partitions reject writes. Design retry/circuit-breaker logic.
3. Do you need XDR or secondary indexes? If yes, SC cannot be used for that namespace.
4. Test before committing. Create a test SC namespace with RF=3 on a 3-node cluster. Run the benchmark and partition simulation above. Verify latency and error behavior match expectations.
5. Monitor from day one. Alert on strong_consistency_quorum_latency p99 > your SLO and raft_leader_changes > 0 per minute sustained.
6. Migration path for existing data. Dual-write to a new SC namespace or use CDC (change data capture) to replicate from AP to SC. There is no in-place conversion.

If the checklist passes, SC gives you linearizable operations with a well-understood failure model. If not, AP with careful conflict resolution remains the pragmatic choice.