That's true in the general case, but there are usually ways to make it not matter. If you have a vector clock with snapshot reads, then you may not know consis

That's true in the general case, but there are usually ways to make it not matter. If you have a vector clock with snapshot reads, then you may not know consistently what the system looks like now, but you can know what it looked like as of some arbitrary previous point in time. If your use case doesn't require read-modify-writes (e.g., metric calculations where the source of truth is out of your control and you just need to aggregate deltas), then that's good enough - you can find a set of results that are in sync with each other, even if they're not fully up to date. If you have limited read-modify-writes, but you can at least engineer synchronous transactions on subsets of the data (e.g., single-row-level transactions) with asynchronous replication and fan-out of side-effects, then you can turn more complex problems into something that looks like the first case. Those tricks alone are enough to remove most of the weirdness with eventual-consistency, but the broader point is that distributed system design is more about learning a toolbox of tricks to handle and describe certain patterns, of which you may have any number in any combination in any given project, than it is about "solving" the problem once and for all.