CSE138 (Distributed Systems) L13: eventual consistency, availability, conflict resolution

UC Santa Cruz CSE138 (Distributed Systems) Lecture 13: eventual consistency; strong convergence and strong eventual consistency; intro to application-specific conflict resolution; network partitions; availability; the consistency/availability trade-off; testing distributed systems
Recorded May 13, 2021
Professor Lindsey Kuper users.soe.ucsc.edu/~lkuper/
Course website: decomposition.al/CSE138-2021-03
Schedule of topics: decomposition.al/CSE138-2021-0...

[@chrisho6836]

For anyone wondering about the clarification at 8:08 - a student notices it too. The question RE: vector clocks at 16:31 was asked b/c the first vector clocks for R1 and R2 were copied incorrectly from the lecture notes i.e., for R1 [1,0,0,1] should have been [1,1,0,0] (R2 has a similar mistake). It is corrected it at the receipt of the second set of messages, but it may make it confusing to follow.

[@ssujeen3034]

Amazing lecture professor. I have one question regarding strong eventual consistency. Would it be right to think if the system guarantees strong eventual consistency, then there is no need for application specific conflict resolution?

[@lindseykuperwithasharpie]

I don't think I would say that. If "the system" is guaranteeing SEC, then it must be doing it in some application-agnostic way, such as last-writer-wins, which is often not what's most helpful for the application. If all you want is SEC by any means necessary, then you can get there without doing any application-specific conflict resolution, but that's kind of a silly thing to want.

[@ssujeen3034]

@@lindseykuperwithasharpie Thanks for the clarification. Apologies in advance if the answer to the following question is obvious. But with SEC, do we need a conflict resolution mechanism such as last-writer-wins? In my understanding, even if there are concurrent writes, wouldn't all the replicas converge to the same value because of the strong convergence property?

[@lindseykuperwithasharpie]

@@ssujeen3034 Well, someone had to implement that mechanism that ensures SEC, whether at the application level or at some underlying "system" level. If the mechanism that ensures SEC is the system level, then you won't need to implement it yourself at the application level. But I would be skeptical of such a mechanism because, since the underlying system doesn't know anything about the application semantics, the only way it can give you SEC is by doing something one-size-fits-all, like last-writer-wins.

[@ssujeen3034]

@@lindseykuperwithasharpie Makes sense, thanks for taking the time to clarify.

[@sahilshah6635]

@Lindsey Kuper ... at 35:00, when we want strong convergence. Can we not implement total-order-broadcast ? This will even guarantee strong consistency!
Or is it because total-order-broadcast is hard to implement... therefore we are not using it?
Because strong consistency implies strong convergence right?

[@lindseykuperwithasharpie]

You could indeed get strong convergence via totally-ordered broadcast, but it would be overkill. The idea here is to identify strong convergence as a useful property that can be accomplished via more lightweight means.