Strong vs Eventual Consistency
A per-operation decision, not a per-system one: whether this specific read must reflect every completed write.
The mistake is deciding it once for a whole system. Almost every real system needs both, and the useful question is asked per operation: what happens if this read is stale by two seconds?
For an account balance gating a withdrawal, the answer is a financial loss, so that read is strong. For a follower count, a product description or a dashboard, the answer is nothing, so those are eventual — and forcing them to be strong buys latency cost and availability risk for no benefit.
Two intermediate guarantees solve most user-visible complaints without going fully strong: read-your-writes (a session sees its own updates) and monotonic reads (a session never sees time move backwards). Both are usually achievable with session-sticky routing, which is far cheaper than global strong consistency.