Enabling Strong Consistency in Aerospike: A Practical Guide

Why Strong Consistency Matters

In a distributed database like Aerospike, the default "eventual consistency" model means that a client may read stale data after a write, especially under heavy load. For applications that require linearizable reads and writes—think banking, inventory control, or real‑time analytics—Aerospike offers a Strong Consistency (SC) mode. This blog walks through the exact steps to enable SC, illustrates a working example, and explains the performance trade‑offs you should consider.

What Exactly Is Strong Consistency in Aerospike?

SC guarantees that once a write completes, every subsequent read from any node will return the new value. Internally, Aerospike routes the write to the master replica and then synchronously updates all other replicas. The client can then read from any replica, but must set the read policy to policy.readModeSC = true to make the database enforce linearizability on the server side.

Key Preconditions

• SC is configured per‑namespace via the strong-consistency flag.
• A namespace must have a replication factor of at least 2; SC is not available for replication‑factor‑1 namespaces.
• All nodes in the cluster must support the same Aerospike version (currently 6.x and above).

Enabling SC: Namespace Configuration

Below is a minimal as.config snippet for a two‑node cluster that turns on SC. Replace <your_host> with your actual node addresses.

namespaces:
  test_ns:
    replication-factor: 2
    storage-engine: memory
    strong-consistency: true
    memory-size: 1G
    commit-interval: 1
    write-block-size: 4096
    wal-mode: native

After editing as.config, restart both nodes. The cluster will now enforce synchronous replication for all writes in test_ns.

Client‑Side Read Policy

Even with SC enabled, the client must request it. In the Java client, for example:

ClientPolicy cp = new ClientPolicy();
cp.readModeSC = true; // Enable strong consistency on reads
AerospikeClient client = new AerospikeClient(cp, "<your_host>", 3000);

For Python, the equivalent is:

client = aerospike.client({
    'hosts': [('<your_host>', 3000)],
    'read_mode_sc': True
}).connect()

When readModeSC is true, the server ensures that the read is served after all replicas have acknowledged the last write, giving you a linearizable view.

Performance Impact and Trade‑Offs

• Write latency typically rises by 20‑40% because the master must wait for the second replica to confirm the write before returning success.
• Throughput may drop proportionally; you should run a benchmark with asbenchmark or a custom loop to quantify the impact in your environment.
• SC does not affect read latency if you read from the master node, but reading from a replica still incurs the extra consistency check.
• Batch reads, scans, and UDF executions can be forced to SC mode by setting the appropriate policy flags; otherwise they default to eventual consistency.
• SC increases network traffic by one round‑trip per write, which can be significant in high‑latency links.

Worked Example: Write and Read with SC

Assume a two‑node cluster (node1, node2) with the namespace test_ns configured as above.

1. Write a record using the default write policy (no SC flag needed on write):

   WritePolicy wp = new WritePolicy();
   Key key = new Key("test_ns", "demo_set", "mykey");
   client.put(wp, key, new Bin("value", 42));
   

2. Read the record with SC enabled:

   Record rec = client.get(null, key);
   System.out.println(rec.bins.get("value")); // Should print 42
   

3. Read without SC to see the difference under load. In a busy cluster, you might observe a stale value (e.g., 41) if the read hits a replica that hasn’t yet applied the latest write.

To verify the difference, run a simple loop that writes a sequence of integers and reads them back with readModeSC true and false, printing any mismatches.

When to Enable SC (and When Not to)

• Use SC if your application requires strict linearizability: financial transactions, inventory adjustments, or any scenario where stale reads could cause data corruption.
• Avoid SC for write‑heavy workloads where latency is critical: session stores, caching layers, or analytics pipelines that tolerate occasional stale reads.
• Consider the replication factor requirement; if you cannot afford an extra replica, SC is not an option.
• Remember that batch and scan operations must explicitly request SC if you need guarantees for those workloads.

Actionable Checklist

1. Verify your cluster has at least two replicas per namespace.
2. Add strong-consistency: true to the namespace section of as.config and restart nodes.
3. Update client code to set readModeSC = true (or the equivalent in your language).
4. Run a benchmark to measure write latency and throughput with SC on and off.
5. Monitor production traffic for increased latency; adjust capacity or consider hybrid consistency models if necessary.
6. Document the change in your deployment notes and inform stakeholders about the expected performance trade‑offs.

Conclusion

Strong Consistency in Aerospike is a powerful feature that delivers linearizable reads and writes at the cost of modest latency overhead. By configuring the namespace correctly, enabling the read policy on the client, and measuring the impact in your workload, you can make an informed decision about whether SC meets your application’s correctness and performance requirements.