- Strict consistency. Every pointer in my b-tree must point to a b-tree node, and not random data which could cause the program to crash. In a financial world, a bank should never print money.
- Fuzzy "good enough" consistency. In the examples in the article, all of the financial transactions should end up close enough to being reconciled.
There's value in both kinds of consistency. When talking about data entered by humans into a database, there's always going to be a bit of slop involved. Someone mistyped a digit. A few records weren't entered at all.
But when building software systems, designing with strict consistency guarantees is such an unbelievably massive win. I can't overstate how important it is. The entire ladder of abstraction in modern computers from transistors all the way up to this website is only possible because each layer "underneath" the layer we're standing on is solid and deterministic. If CPUs made even 1 error in every billion operations, our computers wouldn't boot at all.
Tony Hoare talks about his invention of null pointers as his "billion dollar mistake". Null pointers take something that should be strictly consistent (references) and make it fuzzy. Rust is exciting lots of people in the systems programming space because it takes things that are fuzzy in C (aliasing, memory management, thread-safe variables, etc) and makes them strictly consistent. All the value in unit testing comes from how they make our systems more strictly correct.
Every time I've relaxed consistency guarantees internally in systems I've worked on (or heard coworkers doing the same) we've come to regret it. At a startup several years ago, we needed to build an external search index for a database. The database updated live - and we had a change feed that updated the browsers live as records changed. The engineer in charge did a "good enough" job - he wrote a scrappy script that was only mostly correct. But it sometimes left the index inconsistent with the data. We got constant reports from our users about items not showing up in the search results. He would dutifully go back and fiddle with things to try and fix the problem. Eventually one of our senior engineers went in and rewrote the whole indexing script to be strictly correct. We never heard a peep about it after that - it just worked, every time. Even putting aside the frustration of our users, writing it correctly was a big win for us in terms of maintenance. Once it was correct, we didn't need to keep pulling engineering time away to fix problems.
Maybe data consistency is overrated in databases. But I think if anything, consistency internally in computing systems is underrated. We take for granted how well computers work. But our capacity to make computers do anything depends entirely on those consistency guarantees. It seems ridiculous to disregard its importance.