Today, the inconsistencies here were diagnosed by company and Aerospike to be caused by two clusters connected with XDR concurrently writing data to the same counter and shipping to each other and intentionally overwriting some data (bad design that somehow slipped through the cracks). So, this issue is unrelated to the Jepsen network partitioning tests that is the subject of the original article. The work that @Aphyr is doing is very valuable and much appreciated. (Aerospike Founder)

As Brian's partner in crime as co-founder and an old time DB hand, I do believe modern distributed databases have to not just support scale and performance but also attempt to provide the best ACID consistency possible in the presence of failures. Hopefully, database systems programmers will be interested in learning the details of how Aerospike works, benefit from this, and even help improve it.