What's often missing from these discussions is that the trade off in the CAP theorem can change across the system and over time. If you have a cache on your cli

What's often missing from these discussions is that the trade off in the CAP theorem can change across the system and over time. If you have a cache on your client, you're trading off consistency for availability, same if you do an optimistic update on the client-side. But that does not change the consistency of your database core. You can also "downgrade" to eventual consistency if you detect a network problem. I feel that a more principled way to navigate between these trade offs and awareness from the application and database of the current consistency guarantees of the data would help to make more robust systems. E.g. you'd want strong consistency by default, with a fallback to strong eventual consistency when the network is poor and the use-case allows it (e.g. not for changing your password, but ok for posting a comment). It needs to be reflected in the UI, and ideally you want the trade off to be decided at each level in a consistent way (client, local database, core database, ...).