🤓 Introduction

• Consistency model is a contract between the distributed system and the clients using the application
  • Ex: the model defines rules for allowing concurrent reads or not
  • Systems devs design and optimize the system to meet the contract
  • Application devs understand the contract to interact with the system

DIAGRAM BELOW

• ◀️ ◀️ ◀️ ◀️ Weak consistency to the left
• Strong consistency to the right ▶️ ▶️ ▶️ ▶️
• Discussing these from weakest to strongest below

🐢 Eventual [WEAKEST]

• Once writes to a key stop, all replicas of that key will converge; but until converge the replicas can have different values → as a result, reads can see values from previous writes
• Performance: allows for concurrent writes and increased availability, but needs a way to resolve conflicts between versions in replicas
  • Ex: Cassandra uses latest timestamp

1️⃣ MR, MW, RMW

MR = Monotic Reads

If R1 -> R2 then R2 should return the state of at least what was in R1 , i.e. cannot go back in time

MW = Monotonic Writes

If W1 -> W2 then all clients must see W1 before W2

RMW = Read My Writes

If C1 issues W1 -> R1 then R1 must see the effects on W1 at C1

❓Q) Does causal consistency imply MR? ✅ Yes!

🔁 Casual

• No total ordering (unlike strong models below)
• BUT avoids inconsistencies in eventual by enforcing operations to respect partial order based on information causality
  • Operations from same client are causally ordered
  • Causality is transitive

SEE DIAGRAM

• C3 first R(x) = 0 || 1 because it has no causal relation to C1 W(x=1)
• BUT C3 final R(x) = 1 bc the prev R(y) is causally related to C1 W(x=1)

⏱️ Sequential

• Performance: weaker than linearizable (can have stale reads) but strong compared to above models
• Reads and writes are totally ordered, respecting local order of operations at each client
  • THIS MEANS: if there are multiple operations from same client, those need to be ordered, but don’t need to manage order across clients ead