Aerospike Strong Consistency: Setup, Limits, and Verification

The problem and the useful answer

Two application instances update the same Aerospike record at the same time. With default settings, the cluster may accept both updates without guaranteeing that a later read sees the most recent write in real-time order. If your workload requires linearizable read-modify-write behavior on a single record—meaning every operation appears to take effect instantly at some point between its start and finish—you need Aerospike's strong consistency mode.

The useful answer: enable strong-consistency true in the namespace, set replication factor to at least two, use Aerospike Enterprise Edition, and set ConsistencyLevel.STRONG on both write and read policies. Expect higher write latency and lower throughput in exchange for the guarantee.

How strong consistency works

A namespace is Aerospike's logical database container, similar to a schema or database in other systems. Replication factor is the number of copies of each record stored across cluster nodes. When strong consistency is enabled, the master replica coordinates writes synchronously: it does not report success until replicas have acknowledged the update. A linearizable read then returns the value from the most recent acknowledged write, even if clients are writing concurrently.

This mode depends on synchronized clocks across nodes, typically maintained with NTP. Clock drift can cause false conflicts or slow down the consistency protocol.

Worked configuration example

Edit /etc/aerospike/aerospike.conf on each node. This example uses the in-memory storage engine.

namespace testns {
    replication-factor 2
    storage-engine memory
    strong-consistency true
}

Placeholders: replace testns with your namespace name. Use storage-engine device with an SSD configuration if you are not using memory, but confirm your Aerospike release supports strong consistency on that engine.

In the Java client, set the consistency level on the policy:

import com.aerospike.client.policy.ConsistencyLevel;
import com.aerospike.client.policy.WritePolicy;
import com.aerospike.client.policy.ReadPolicy;
import com.aerospike.client.Key;
import com.aerospike.client.Bin;

// Write
WritePolicy wp = new WritePolicy();
wp.setConsistencyLevel(ConsistencyLevel.STRONG);
Key key = new Key("testns", "demo", "user:123");
Bin bin = new Bin("counter", 1);
client.put(wp, key, bin);

// Read
ReadPolicy rp = new ReadPolicy();
rp.setConsistencyLevel(ConsistencyLevel.STRONG);
Record record = client.get(rp, key);

The namespace name in the client key must match the namespace in aerospike.conf. Setting the policy on only the write side is not enough; reads should also use STRONG when you need the latest acknowledged value.

Verify the setting

Run this command from a shell on any cluster node:

asinfo -v 'get-config/:context=namespace;id=testns;strong-consistency'

Where to run: the Aerospike server host. Required permissions: shell access as the aerospike user or with sudo. Expected output: true. If the output is missing or false, the namespace was not started with strong consistency enabled. Risk: a typo in the namespace identifier returns no useful value rather than an obvious error.

Also check node startup logs at INFO level for a message indicating strong consistency is enabled for the namespace. Absence of that message is a strong signal the flag did not take effect.

Practical verification test

To confirm behavior, run two clients that write the same record concurrently, both using ConsistencyLevel.STRONG. After both writes complete, read the record. The final value should match the last write in real-time order. This test does not prove linearizability by itself, but a result that contradicts real-time order indicates the setting is not active or not working as expected.

Limits and trade-offs

• Enterprise Edition only. Strong consistency is not available in Community Edition.
• Storage engines. Supported on memory and SSD/device storage; confirm your storage configuration in the release notes.
• Replication factor. Must be at least two. A factor of one cannot provide replica coordination.
• Performance. Write latency typically increases, often by a factor of two to five, and overall throughput can drop under load because writes wait for replica acknowledgment.
• Feature incompatibilities. Strong consistency cannot be combined with Large Data Types (LDTs) and may not work with certain secondary index types. Check your version's documentation before enabling it on a production namespace.
• Clock dependency. NTP synchronization across nodes is required; drift can cause false conflicts or performance degradation.

Common mistakes

• Setting replication factor to 1 and expecting strong consistency.
• Adding strong-consistency true to the configuration file but forgetting to restart the namespace or cluster.
• Assuming a client-side STRONG policy is sufficient without the namespace flag.
• Expecting cluster-wide consistency when only one namespace is enabled; other namespaces remain unaffected.
• Believing strong consistency removes the need for application-level idempotency. Retried writes can still be applied more than once unless your application handles deduplication.

Changing state and rollback

Editing aerospike.conf and restarting Aerospike changes cluster state. To roll back, change strong-consistency true to strong-consistency false, restart the affected namespace or node, and verify with the asinfo command above. Plan for a brief interruption during the restart.

Checklist before enabling

• Aerospike Enterprise Edition is installed.
• Replication factor is two or greater.
• NTP is synchronized across all cluster nodes.
• Client code sets ConsistencyLevel.STRONG on reads and writes.
• You have accepted higher latency and lower throughput.