The Problem with Lying is Keeping Track of All the Lies
“The real difficulty with lying is that you have to keep track of all the lies that you’ve told, and to whom” is a quote I once read that I can’t definitively source (it’s… inconsistently attributed to Mark Twain). It’s stuck with me because it captures the logic as to why it’s so hard to be productive as a programmer in a world of weak isolation models.
[Author’s note: database communities use the term “isolation,” and distributed systems communities use the term “strong consistency,” to refer to overlapping concepts. In the rest of this post, I will stick to the database terminology because this is all their fault in the first place.]
If you lie to someone, you have to remember all the other things you’ve told to everyone else, and game out who might be talking to whom. Then, you have to reason about how you could get caught. This slows down your thinking and mental agility. Similarly, if you work with data platforms that do not provide strong isolation, you have to carefully consider how this might lead to error states or end-user visible inconsistencies. You’re potentially telling “lies,” and you need to keep track of them.
This slows down your development velocity. Most of your time is spent reasoning about architecture diagrams. You might be giving an inconsistent read to an unsuspecting client. You have to keep track of what services are not communicating through the database. I concede that the “lie” metaphor might be provocative, but it’s a good approximation for what an “anomaly” is in practice. And lying is a solid framework for understanding the concept of database consistency.
