Distributed Systems 7.3: Eventual consistency

[@mostinho7]

Thanks! 1:00 linearizability advantages disadvantages 8:00 eventual consistency formally 10:55 consistency models

[@mrfchannel142]

I already immensely enjoyed the DDIA book, but for me being more of a visual/interactive learner this is just a total gem. Thanks a lot for making those lectures public, Martin!

[@aliwassouf]

You have an outstanding ability to explain things, thanks for the effort. I hope to see more from you. I am preparing for system design interviews and this video is one of the gems in my collection now

[@zhou7yuan]

Eventual consistency Linearizability advantages Linearizability Downsides [0:32] (calendar app example) [2:13] (phone airplane mode conflict) [3:08] The CAP theorem [4:59] Eventual consistency [6:31] Strong eventual consistency [7:55] Eventual delivery Convergence [8:23] Properties [9:13] Summary of minimum system model requirements [11:01] atomic commit consensus | total order broadcast | linearizable CAS linearizable get/set eventual consistency | causal broadcast | FIFO broadcast

[@tirumaleshy9636]

Good stuff martin! Please keep updating new lectures from DDIA

[@manveersingh5822]

That calendar example was so good sir. Thanks!

[@guessWhoWhenWhere]

Exactly

[@OKJazzBro]

13:40 Linearizable get/set would need quorum + _synchronous_ read repair right? If the read repair is done asynchronously, another get operation could execute before the read repair happens and get an older value from stale replicas thus violating linearizability.

[@mohamedbalshy3105]

exactly what i was thinking about, how it need a quorum and async ?

[@hpandeymail]

Great Content Shree Martin .. thanks for sharing such good insights across all your videos.

[@andrewzhurov5123]

Excellent material.

[@navneetmishra367]

So I tried doing the same in Google Calendar. In the desktop app, I updated the time, and in the mobile app, I updated the title. Post connecting to the internet on my phone, I saw both calendar versions synced with modified time and modified title.

[@arturuklejewski7339]

Great presentation ! Thank you for sharing.

[@umamaheshsukamanchi]

Very well explained.thanks for sharing.

[@benjaminkuchcik4600]

If the isolated node in the Quorum receives user update and crash (by example hard vm & disk crash, you are not lucky), it means that the Eventual Consistensy implies data loss when network failures happens ? In the example of the Calendar, it could lead to a calendar entry totaly removed.

[@Ondra011]

Good point, although it doesn't seem like a proper formal definition of eventual consistency was given, it sounds like that situation would violate the invariant that all replicas end up in the same state. Eventual delivery fixes this by only talking about non-faulty replicas.

[@shoumikghosal]

Interesting point! Maybe a new data object being created locally in an isolated/partitioned node involves some bit updates/logging to the local permanent storage? Since otherwise not having an internet connection would mean the calendar app loses a perfectly valid new entry after a crash.

[@rohankathpal7642]

No it won't, because if it was written to the oplog of the replica before the crash, then it would reflect the change in the replica, and if it's not written in the oplog, the replica would copy all the transactions until it's oplog looks same as the oplog of the master node.

[@satinek]

I really liked the presentation of the calendar example. I‘ve heard this example before but not as well presented as here.

[@iSumitYadav]

How the last write win policy working? Last write was made by iphone and not mac!

[@yihanwu3823]

I think this is kind of misleading, as the info got lost just because the network was cut off and could not even make a write to server.

[@vhscampos1]

Last write was made by the Mac (edit: iPhone) only if write order is defined by actual time of the day (physical clock). It it is instead defined by logical clocks, like Lamport clocks, it could be the case that both writes had the same Lamport clock, but the Mac won out because it had a lesser node ID, for example.

[@florayym]

@@vhscampos1 I am a little confused about the first part of your answer. According to the physical clock, isn't the case that the last write was made by iPhone, not Mac? I think it makes sense that it's actually "defined by logical clocks". And when logical clocks are the same, they compare node ID to decide who makes the last write.

[@vhscampos1]

@@florayym My mistake indeed. I meant iPhone where I wrote Mac.

[@2tce]

@@yihanwu3823 Agreed. It was offline. Zero communication with any replicas. So when it came back online it got updated with the latest. The offline phone update was a never written. So there is no such thing as LAST WRITE in this case. So yes, I agree with you that this example was off, and misleading.

[@blocksmithbrothers]

In case of eventual consistency where read and writes are processed at local, how we can guarantee durability if local crashes after acknowledgement of write but further disseminating to other nodes?

[@abhinavghosh725]

the calendar example was impressive

[@420_gunna]

Anyone know the "AVD" algorithm that he's talking about? Hard to google

[@mehdisaffar]

I believe it is ABD algorithm, as stated in the lecture notes