5 ms·

So CAP: which does gun throw off the island? Based on this statement ... > It bridges the distance with a realtime connection, so updates propagate at the spe

So CAP: which does gun throw off the island? Based on this statement ... > 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.

dantiberian 13y ago
CA system's don't exist so it must be CP or AP. 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-theorem https://foundationdb.com/white-papers/the-cap-theorem
- GregorStocks 13y ago
  It could also be neither, which is a popular choice these days.
marknadal 13y ago
Out of the box gun only guarantees you eventual consistency, not strong consistency. The reason why is because the majority of web applications out there today are manipulating data sets that aren't particularly significant or regulated (tweets compared to medical records, profile updates compared to payment information). As a result, gun opts for high availability so response times are fast for users, and assuring their data won't be lost. However, 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.

dantiberian 13y ago

CA system's don't exist so it must be CP or AP. 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-theorem https://foundationdb.com/white-papers/the-cap-theorem

GregorStocks 13y ago
It could also be neither, which is a popular choice these days.

marknadal 13y ago

Out of the box gun only guarantees you eventual consistency, not strong consistency. The reason why is because the majority of web applications out there today are manipulating data sets that aren't particularly significant or regulated (tweets compared to medical records, profile updates compared to payment information). As a result, gun opts for high availability so response times are fast for users, and assuring their data won't be lost. However, 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.