Brilliant article! Very interesting to get a a glimpse of what confluence and convergence mean.
Two minor comments that might improve the decipheration of cross-domain consistency:
- Linearizability (single object - real time guarantee) is a better match with Strict serializability (across object - real time). Sequential consistency (single object - logical time) matches with Serializability (across object - logical time).
- Consensus is not necessary for distributed write operations - even for systems tolerating faults under synchrony (see ABD). Rather consensus is necessary to implement operations with Read-modify-write semantics.
Nice comment!!! I just spent the last 11 hours updating this blog post to have more stuff (I got carried away). I just saw this comment as I'm about to post the longer version.
Some of your comments, I caught today. Others, I'm going to put into a different post about serializability, linearizability, and replication. That may not happen until next weekend, though.
Absolutely no pressure. I just enjoy your post and thought that I could potentially provide some potentially useful points to your efforts. I look forward to your future posts :)
Awesome summary! I've always thought of "eventual consistency" as being more of a description of system behavior rather than a specific function on consistency; somewhat more like the sealing of confluent streams, but not quite. What I usually have in mind is traditional contract law/promises, where various components are making statements about "transactions" which are really just promises of a future state being consistent with what we promised in the past. Hence, not really transactions at all, but more systemic in terms of how people work/shop/deliver real goods.
It would be fun to chat via video! There are lots of these ideas you mentioned within the Autonomous Computing post on this blog. On another note, I have a ton of thoughts about the interactions between REST and "happened-before" that I'd love to bounce around.
Great fleshing out of these concepts! However Lamport's ordering is defined in terms of the messages that are received, so is there circularity in the definition of linearizability? (No pun intended!)
I may be wrong but I think both Linearizability and "happened-before" BOTH talk about messages received. Did I mess up in making the definitions circular? I don't see it if I did.
Brilliant article! Very interesting to get a a glimpse of what confluence and convergence mean.
Two minor comments that might improve the decipheration of cross-domain consistency:
- Linearizability (single object - real time guarantee) is a better match with Strict serializability (across object - real time). Sequential consistency (single object - logical time) matches with Serializability (across object - logical time).
- Consensus is not necessary for distributed write operations - even for systems tolerating faults under synchrony (see ABD). Rather consensus is necessary to implement operations with Read-modify-write semantics.
I have been thinking a lot about when and why consensus is required. It truly messes up liveness and it AIN'T needed most of the time!
Thanks, again, for your comments!
Nice comment!!! I just spent the last 11 hours updating this blog post to have more stuff (I got carried away). I just saw this comment as I'm about to post the longer version.
Some of your comments, I caught today. Others, I'm going to put into a different post about serializability, linearizability, and replication. That may not happen until next weekend, though.
Absolutely no pressure. I just enjoy your post and thought that I could potentially provide some potentially useful points to your efforts. I look forward to your future posts :)
Under asynchrony*
Synchronous and asynchronous are subjective terms. :-)
Thank you for your interest and support!
Awesome summary! I've always thought of "eventual consistency" as being more of a description of system behavior rather than a specific function on consistency; somewhat more like the sealing of confluent streams, but not quite. What I usually have in mind is traditional contract law/promises, where various components are making statements about "transactions" which are really just promises of a future state being consistent with what we promised in the past. Hence, not really transactions at all, but more systemic in terms of how people work/shop/deliver real goods.
Hey, Roy!
It would be fun to chat via video! There are lots of these ideas you mentioned within the Autonomous Computing post on this blog. On another note, I have a ton of thoughts about the interactions between REST and "happened-before" that I'd love to bounce around.
Holler if you want to chat!
Pat
Great fleshing out of these concepts! However Lamport's ordering is defined in terms of the messages that are received, so is there circularity in the definition of linearizability? (No pun intended!)
I may be wrong but I think both Linearizability and "happened-before" BOTH talk about messages received. Did I mess up in making the definitions circular? I don't see it if I did.