1. Consistency without consensus Linearizable Resilient Data Types (LRDT) Kaushik Rajan Sagar Chordia Kapil Vaswani Ganesan Ramalingam Sriram Rajamani

2. Consistency & consensus Add(The Hobbit) Add(Kindle) GetCart() Processes agree on ordering of operations GetCart() No deterministic algorithm in the presence of failures [FLP]

3. Commuting updates What if all update operations commute? –Ordering of updates doesn’t matter! –Eventual consistency reduces to eventual message delivery –Single round trip latency What if we desire linearizability? –Updates don’t commute with arbitrary reads  –Reads must be consistently ordered with updates –Semantics of queries like the current top(k) elements well understood

4. Commuting updates Add(The Hobbit) Add(Kindle) GetCart() {} {The Hobbit, Kindle} Reads must observe comparable sets of operations

5. Linearizable resilient data types Possible Impossible Don’t know S S’ op 1 op 2 op 1 op 2 P 1 : commutes(s,op 1,op 2 ) op 1 op 2 S S1S1 S2S2 op 1 P 2 : nullify(s,op 1,op 2 ) op 2 S S1S1 S2S2 op 1

6. Examples Read write register : every pair of writes nullify Read write memory : writes to the same location nullify, writes to different locations commute

7. Examples Set : add, remove and read the whole set –Add(u), Remove(v) commute –Add(u), Remove(u) nullify –Add(*), Add(*) commute –Remove(*) Remove(*) commute Counter : IncrBy(x), DecrBy(x), SetTo(v), Read() –SetTo(v) nullifies all other operations –Other pairs of updates commute Other examples Heaps, union-find, atomic snapshot objects…

8. Lattice agreement Consistency reduces to lattice agreement –Weaker problem than consensus –Solvable in an asynchronous distributed system Assumptions –t < n/2 failures –Eventual message delivery

9. Lattice agreement

10. a = Add(The Hobbit) b = Add(Kindle) c = Add(Lumia)

11. All Acks ? wait for majority of acceptors to respond Y N Y N PROPOSERSACCEPTORS

12. AckNack Output proposal

13. Safety and liveness Safety always guaranteed Lattice agreement is t-resilient –Liveness guaranteed if quorum of processes are non-faulty and communication is reliable –Processes output value in at-most n round trips, where n is the number of processes

14. Generalized lattice agreement Generalization of lattice agreement –Processes receive sequence of values –Values belong to an infinite lattice Processes output a sequence of values –(Validity) Every output value is a join of some received values –(Consistency) Any two output values are comparable (i.e. output values form a chain) –(Liveness) Every value received by a correct process is eventually included in an output value

15. GLA algorithm Liveness (t-resilient) –Every received value is eventually included in some output in n round trips –Adaptive, complexity depends on contention Fast path –Received values output in one round trip Reconfigurable –Replicas can be added/removed dynamically

16. From GLA to linearizability Update commands form power set lattice Updates return once majority of processes have learnt a command set that includes the update command Read performed by (ABD style algorithm) 1.reading the learnt command set from a quorum of processes 2.Writing back the largest among these to a quorum 3.Constructing state corresponding to the largest command set by exploiting commutativity and nullification Multi-master replication –Does not require a single primary/leader

17. Impossibility Consensus reduction Consensus(b) S i  S 0 if(b) then op1 else op2 s = read() if(s = S 1,S 12 ) return true else return false Pair of idempotent update operations that neither commute nor nullify at some state s 0 S0S0 S1S1 S12S12 S2S2 S21S21 op 2 op 1 op 2 SiSi Op* op 2 op 1

18. Implications for designing ADTs

20. The Gap : Open problems Doubly saturating counter 0 1 Incr() Decr() 2 Incr() Decr() n Incr() Decr() Incr() Incr() and Decr() commute at 1 … n-1 Incr() and Dect() nullify at 0 and n Don’t know if this is possible or impossible

21. Summary Possible Impossible ?? Saturating counter