> It bridges the distance with a realtime connection, so updates propagate at the speed of the raw pipes linking them.
... I'm assuming it's the P.
> It bridges the distance with a realtime connection, so updates propagate at the speed of the raw pipes linking them.
... I'm assuming it's the P.
However, further consideration shows that CA is not really a
coherent option because a system that is not Partition-
tolerant will, by definition, be forced to give up
Consistency or Availability during a partition.
https://foundationdb.com/white-papers/the-cap-theoremHowever, the strength of this design is it allows you to implement stronger forms of consistency on top - which is necessary for those occasional pieces of data (payments, medical records, etc). But if you do this then the availability of that data diminishes because servers must wait for consistency to be achieved before doing any further transformations. The sweet spot about this is that it will only be the availability of that particular property (or properties that it depends upon) that decreases, all other pieces of information will still be snappy fast because gun is capable of locking at a granular level.
This will not be as "easy" as it is in databases that are strongly consistent to begin with, but those databases aren't capable of being eventually consistent either (because that would violate the DB's principles). But it is possible, and you the developer get the control and flexibility over that. So you win some and you lose some, but I believe this setup is highly optimized because generally speaking the things that you need to be "strongly consistent" anyways have much slower "weakest links" than the speed of networks being up or down - such as approval by some human overseer (a loan officer, a lawyer, a doctor, etc.), and meatspace brains take much longer to process regulatory issues than the potentially couple of hours the network might be down. I'll touch more on these quirks in a separate post after I address conflict resolution.