If you start with the intention of asynchronous, non-transactional eventual consistency as your assumptive design model, you'll realise:
1. Most applications don't need 100% correctness. Few people are writing nuclear reactor control systems, or bank account management software
2. This model frees you to up to compute at the edge more.
Is there a chance that you consider something valid that eventually wasn't? Yes. But in a single actor-per interaction system (e.g. an single actor mutating something, multiple people seeing effects, etc.), typical to the web, this is OK.
People know about CAP theorem but hang onto the C with dear life. Let it go. It makes everything easier. Honest.
You make some good points, but I disagree that giving up consistency makes everything easier. There are trade-offs. In an eventually consistent system, in my experience, application code becomes much more complex to implement, test and debug.
1. Most applications don't need 100% correctness. Few people are writing nuclear reactor control systems, or bank account management software
2. This model frees you to up to compute at the edge more.
Is there a chance that you consider something valid that eventually wasn't? Yes. But in a single actor-per interaction system (e.g. an single actor mutating something, multiple people seeing effects, etc.), typical to the web, this is OK.
People know about CAP theorem but hang onto the C with dear life. Let it go. It makes everything easier. Honest.