Aerospike Strong Consistency: Fixing Duplicate Deductions in Payment Workloads

Problem: duplicate deductions from concurrent writes

A global payment gateway once logged duplicate deductions when two application servers simultaneously charged the same customer's account. Both threads read the current balance calculated the new amount and wrote it back to Aerospike using the namespace's default read-write policy. Because the default mode is eventual consistency the two writes conflicted and the final balance reflected only one update leaving the other transaction's deduction unrecorded.

Takeaway: enable strong consistency where it matters

Enabling Aerospike's strong-consistency mode with the right read and write policies eliminates these race conditions while keeping latency within acceptable bounds for high-throughput services.

What strong consistency changes

Aerospike's default read-write policy is eventual consistency. Replicas may lag and a read can return a value that hasn't seen the latest write. Strong consistency changes this by requiring that every write be acknowledged only after all replicas have persisted the record and every read must consult all replicas to return the most recent value.

Key terms:

• Strong-consistency flag: a namespace-level setting that turns on linearizable reads and writes.
• COMMIT_LEVEL_ALL: the write policy that tells the client to wait for acknowledgments from every replica before returning success.
• CONSISTENCY_LEVEL_ALL: the read policy that forces the client to read from all replicas and return the newest value.

Configuration example

To activate strong consistency add the strong-consistency flag to the namespace block in aerospike.conf and set a replication factor of two or more.

namespace payments { replication-factor 2 strong-consistency true # other settings ... }

On the client side configure the write and read policies:

// Write with commitLevel All policy.writePolicy.commitLevel = CommitLevel.All; // Read with consistencyLevel All policy.readPolicy.consistencyLevel = ConsistencyLevel.All;

Where to run diagnostics on any cluster node with Aerospike tools installed run asinfo -v 'strong-consistency'

Required permission: administrative access to the Aerospike cluster. Meaningful placeholder: replace payments with your namespace name. Expected check: the output should show strong-consistency enabled and current metrics. Risk: if a replica is down the command may report errors or reduced metrics confirming the availability impact.

Trade-offs and limitations

Strong consistency comes at a cost. Because each write must reach all replicas before acknowledging latency increases. Under heavy load throughput can drop by roughly 20-30% compared with the default eventual-consistency mode. Network utilization rises proportionally to the replication factor. Additionally if any replica is unavailable writes will time out or fail reducing availability the CAP theorem trade-off in action.

SSD wear is another consideration: the extra write traffic accelerates drive degradation. Monitor drive health with SMART data and consider over-provisioning SSD capacity or tuning the write-block-size to mitigate the impact.

Verification: a practical checklist

1. Create a test namespace with replication-factor 2 and strong-consistency true in aerospike.conf restart the cluster.
2. Using a client configured with commitLevel: CommitLevel.All write a record e.g. an account balance and note the returned value.
3. Immediately perform a read with consistencyLevel: ConsistencyLevel.All from a separate client thread and verify that the returned value matches the written value.
4. Simulate a replica failure by stopping one Aerospike node. Observe that the write operation now times out or returns an error confirming the availability impact.
5. Measure latency and throughput with the asbenchmark tool before and after enabling strong consistency to quantify the trade-off for your workload.

If the latency increase stays within your SLA and the availability impact is acceptable strong consistency is a viable path for ledger updates inventory reservations or fraud-scoring workloads.

Actionable closing

If your workload tolerates the latency cost enable strong consistency on namespaces where data correctness is non-negotiable. Keep the replication factor minimal but sufficient 2+ over-provision SSD write buffers and watch the strong-consistency metrics via asinfo -v 'strong-consistency'. For workloads that can accept eventual consistency stick with the default policy and rely on Aerospike's conflict-resolution mechanisms instead.