1. Molecular Transactions G. Ramalingam Kapil Vaswani Rigorous Software Engineering, MSRI

2. Simple banking application Rigorous Software Engineering Microsoft Research, India let transfer from to amount = atomic { match hasBalance from amount with | true -> debit from amount credit to amount SUCCESS | false -> INSUFFICIENT_BALANCE } Application server Database Account#NameBalance XXXX0123ABC10000 XXXX3452XYZ20000 ACID Transaction

3. Rigorous Software Engineering Microsoft Research, India ?

4. Scalable applications Support lots of users – TBs of data! – Many concurrent transactions – Unpredictable workload Key requirements – Available – Fault tolerant – Data consistency Achieving all at the same time non-trivial! Rigorous Software Engineering Microsoft Research, India Application server Relational Database

5. Designing for scale Rigorous Software Engineering Microsoft Research, India

6. Scaling application tier Rigorous Software Engineering Microsoft Research, India Application server Database

7. Replication Rigorous Software Engineering Microsoft Research, India Application server Replica

8. Data partitioning Rigorous Software Engineering Microsoft Research, India Application server Data partition Data partition A first-class citizen in cloud based storage systems

9. Horizontal data partitioning Rigorous Software Engineering Microsoft Research, India let transfer from to amount = let status = atomic { match hasBalance from amount with | true -> debit from amount DEBIT_COMPLETE | false -> INSUFFICIENT_BALANCE } atomic { match status with | DEBIT_COMPLETE -> credit to amount SUCESSS | _ -> INSUFFICIENT_BALANCE } Database partition Database partition BranchAccount#NameBalance XXXX01XXXX0123ABC10000 BranchAccount#NameBalance XXXX34XXXX3452XYZ20000 Distributed transactions do not scale  Azure tables, BigTable, Dynamo do not support distributed transactions! Distributed vs. local transactions

10. Consistency Rigorous Software Engineering Microsoft Research, India let transfer from to amount = let status = atomic { match hasBalance from amount with | true -> debit from amount DEBIT_COMPLETE | false -> INSUFFICIENT_BALANCE } atomic { match status with | DEBIT_COMPLETE -> credit to amount SUCESSS | _ -> INSUFFICIENT_BALANCE } Database partition Database partition Account#NameBalance XXXX0123ABC 5000 Account#NameBalance XXXX3452XYZ 20000

11. Rigorous Software Engineering Microsoft Research, India

12. Compute failures Rigorous Software Engineering Microsoft Research, India let transfer from to amount = let status = atomic { match hasBalance from amount with | true -> debit from amount DEBIT_COMPLETE | false -> INSUFFICIENT_BALANCE } Database partition Database partition Account#NameBalance XXXX0123ABC 5000 Account#NameBalance XXXX3452XYZ 20000 Server failures

13. Handling compute failures Rigorous Software Engineering Microsoft Research, India let transfer from to amount = let status = atomic { match hasBalance from amount with | true -> debit from amount DEBIT_COMPLETE | false -> INSUFFICIENT_BALANCE } Database partition Database partition Account#NameBalance XXXX0123ABC 5000 Account#NameBalance XXXX3452XYZ 20000 atomic { match status with | DEBIT_COMPLETE -> credit to amount SUCESSS | _ -> INSUFFICIENT_BALANCE } Checkpoint storage

14. There’s more…logical failures Rigorous Software Engineering Microsoft Research, India let transfer from to amount = let status = atomic { match hasBalance from amount with | true -> debit from amount DEBIT_COMPLETE | false -> INSUFFICIENT_BALANCE } Database partition Database partition Account#NameBalance XXXX0123ABC 5000 Account#NameBalance XXXX3452XYZ20000 What if credit fails? e.g. account closed

15. Handling logical failures with compensating actions Rigorous Software Engineering Microsoft Research, India let transfer from to amount = let status = atomic { match hasBalance from amount with | true -> debit from amount DEBIT_COMPLETE | false -> INSUFFICIENT_BALANCE } Credit fails let compensate from amount = atomic { credit from amount }

16. Molecular transactions Fault-tolerant composition of atomic transactions with compensating actions Rigorous Software Engineering Microsoft Research, India ⇋ ⇋ ⊗ molecule { }

17. Account transfer with MT let transfer from to amount = molecule { do! atomic { match hasBalance from amount with | true -> debit from amount | false -> abort } |> compensateWith <| atomic { credit from amount } return! atomic { match exists to with | true -> credit to amount | false -> abort } Rigorous Software Engineering Microsoft Research, India First atomic step Compensation Second atomic step Hides Serialization Messaging Fault tolerance No isolation Compensating actions must semantically undo

18. Implementation Rigorous Software Engineering Microsoft Research, India

19. System model Compute agents – May fail at any time – System detects failure and restarts agents – All agent-local state is lost Partitioned storage – Partitions are units of serializability Persistent queue – Communication between agents Rigorous Software Engineering Microsoft Research, India

20. Persistent queue Not really a queue! – Out-of-order – At-least once Operations – Enqueue(m) – Get() Gets a message, makes message invisible Message re-appears if not dequeued – Dequeue(m) Permenantly deletes the message Rigorous Software Engineering Microsoft Research, India

21. Tolerating agent failures Agent can fail between transactions Check-pointing – Check-point state after every transaction Rigorous Software Engineering Microsoft Research, India

22. Check-pointing Rigorous Software Engineering Microsoft Research, India EnqueueRead Database partition Database partition Dequeue

23. Compute failures Rigorous Software Engineering Microsoft Research, India Read Database partition Dequeue Enqueue Transactions may be evaluated more than once! Messages may be sent more than once!

24. Idempotence Instrument transactions for idempotence – Assumes key-value store with a unique key constraint – Assign each atomic step in each MT a unique id – Add (unique id, return value) to write set – Idempotence log in transaction’s partition If transaction evaluates more than once – Unique key violation causes transaction failure – Return stored value Rigorous Software Engineering Microsoft Research, India

25. Summary Molecular transactions – Language abstraction for programming weakly consistent applications – Hides messaging, queuing, fault tolerance – Expressed using a monad, lends to declarative, bug-free code Efficient implementation on cloud based storage systems – Does not require 2PC! – Built a number of applications on Azure – < 10% overheads over hand-written code Rigorous Software Engineering Microsoft Research, India

26. Open questions Specifying and reasoning about correctness of molecular transactions Declarative ways of making consistency/performance trade-offs Do cloud-based systems provide right primitives? Rigorous Software Engineering Microsoft Research, India

27. Thank you Questions? Rigorous Software Engineering Microsoft Research, India