3 ms·
I don't think that necessarily follows? I don't see why you can't have very intuitive and logical inconsistency. To give a super simple example, imagine a data
by im3w1l 5y ago
I don't think that necessarily follows? I don't see why you can't have very intuitive and logical inconsistency.
To give a super simple example, imagine a database on two servers A and B. A is the canonical copy, and updates are streamed to B. All responses from A and B are of the form "the data as of <time> was x". During a partition B will simply serve increasingly stale data.
- eloff 5y agoI'm not exactly sure what your point is. Inconsistent systems are not always horrible? Mostly they behave well. It's really that they have edge cases that are unintuitive. In your example of a user is switching between A and B all the time, imagine their confusion as their changes keep getting lost and reappearing. Now imagine they make other changes based on that situation. This can also happen with different users communicating via a side channel.
- loopz 5y agoIn practice infrastructure is more complex than client-server, even if distributed. So inconsistencies may propagate in semi-random ways. Interestingly this happens in physical systems too, something accounting and banks provide means to mitigate.
- ithkuil 5y agoWhat you're describing is a single writer distributed system, which is one way to achieve consistency. Since you can't write directly to server B, the system is unavailable for writes when a writer happens to live on the side of the network partition where B is located. Often when discussing "availability", it's very important to qualify for whom and for which operations.