The "Strong Consistency" Lie
If you read the marketing page of any distributed database—NoSQL or NewSQL—it will likely promise "Strong Consistency," "Zero Data Loss," and "100% Availability." For years, developers trusted these claims and built production systems on top of them. Then came Kyle Kingsbury (known online as Aphyr).
Kingsbury wrote a software framework called Jepsen and used it to subject popular databases—MongoDB, PostgreSQL, Elasticsearch, Cassandra, RabbitMQ, and dozens more—to realistic network failures while those databases were actively serving traffic. The results were damning. Almost every major database was found to lose data, resurrect deleted records, or violate its advertised transaction guarantees the moment the network got slightly flaky. These weren't exotic edge cases; they were the kinds of failures that happen in real data centers every week.
What is Jepsen?
Jepsen is not just a tool; it is a verification philosophy. It is designed to answer one question with mathematical rigor: "When the network breaks, does the database actually do what it promised to do?" It does this by combining controlled fault injection with formal correctness checking—running real workloads against a real cluster, deliberately breaking things, and then proving whether the resulting history of operations is consistent with the database's claimed guarantees.
The Jepsen project has published analyses of over 30 databases. In almost every case, the analysis found at least one scenario where the database violated its own documentation. This is not a knock on the engineers who built those systems—distributed systems are genuinely hard. It is a knock on marketing copy that overpromises, and on the industry's prior lack of rigorous testing tools.
Interviewers at companies running large distributed systems (Stripe, Cloudflare, Cockroach Labs, etc.) sometimes ask: "How would you verify that a database actually provides the consistency guarantees it claims?" The expected answer is not "read the docs." It is: run adversarial tests under network partition and clock skew, then formally verify the operation history against the claimed consistency model. Jepsen is the canonical tool for this. Mentioning linearizability checking by name signals senior-level understanding.
Key Point: Jepsen exposes the gap between marketing claims and actual behavior under realistic failure conditions. The gap is almost always larger than vendors admit.