How do we deal with information inconsistency and even information loss in the "real world?" We infer from context (fill in the blanks), and we attempt to confirm, wait, and repeat operations as new facts come in. As with double-entry accounting, we try to take a "compensating action" to account for the times we are wrong.
According to Boner, the path forward is to treat time as a first-world construct instead of an unmodeled implied item. To do that, you can't go around "changing things," insert only or doing away with CRUD in favor of only CR. In other words, we make records or "facts" immutable. This obviously goes all the way from the front end of the system to the storage.
A popular explanation of transactions uses the bank account. Assuming I have a bank account and you have a bank account and I want to transfer money to you, we open up a nice transaction (which locks both accounts) and subtract money from my account and add money to yours. If I don't have enough money the transaction rolls back. If your account can't receive the money it rolls back. This allows us to know exactly how much money we have in our bank accounts at any given time.
The only problem with this analogy is that no banking system has ever worked or will ever work this way. What do banks use? They use credits, debits, and compensating transactions. There are financial exchanges "in flight," which are in various states of completion. If something wrong happens, the bank takes compensating action. Even with a bank, the answer to the question "How much money do I have in my account right now?" is a type of fiction told to make customers feel better.
Boner's idea is to define "consistency boundaries" that describe the time, place, and circumstances in which the answer we give is correct. Outside of those boundaries is chaos. This starts to look a lot more like physics than computing, but that's a more honest approach.
That said, we have a long way to go before business and developers come to terms with how much lying they do to achieve a false sense of simplicity. The idea of "strong consistency" is ingrained in the minds of many. I mean, I recently had a client design an audit log that required updates.
If you haven't caught Boner's "Life Beyond the Illusion of Present," I highly recommend it. I'd take some of the prescription (obviously this is a long pitch forLightbend/Akka) with a grain of salt, but the problem is well stated. From a person who has developed both strongly consistent and highly concurrent systems, I can say Boner's talk makes me even less enamored of crusty old Oracle DBAs and their pre-seventh-century ways.
Sign up for CIO Asia eNewsletters.