4 ms·
The partition part is about how tolerant your system is to a partition situation. Having massively reliable communications between systems will reduce your MTB
by dedward 13y ago
The partition part is about how tolerant your system is to a partition situation. Having massively reliable communications between systems will reduce your MTBF, but it doesn't address how your system will actually handle a partition. You do need to account for it one way or the other. If you get a partition, you can't keep operating with consistency across the whole system.
Now when you look at patient data .. sure, eventually consistent might be just fine.. but that's not consistency as referred to in CAP. So while it's perfectly acceptable to your app, it's not about making CAP invalid.
- superuser2 13y ago>If you get a partition, you can't keep operating with consistency across the whole system. But why can't I shut down some nodes and direct all my users to the other(s)? As long as I have enough of a channel to communicate which node is now authoritative (and if all systems including driving between DCs fail simeltaneously, nobody needs my app anyway) can't I keep serving my users out of one DC? Thank you for engaging this thought experiment, by the way. This is fascinating stuff.
- Scramblejams 13y agoAs the linked site notes, clients are part of the distributed system, which means they can be partitioned as well, both from each other (more important in a P2P app) and from your servers. So you may not be able to "direct all your users to the other(s)."