1. Dynamo Kay Ousterhout

2. Goals Small files Always writeable Low latency – Measured at 99.9 th percentile

3. Non-goals Untrusted nodes Relational schema Hierarchical namespace

4. Big (Old?) Ideas

5. Replication: Store every object on N nodes N = 3

6. Consistent Hashing C B A G F DE Key

7. Consistent Hashing C B A G F DE Key H

8. Consistent Hashing + Virtual Nodes C B A G F DE Key H

9. Conflict Resolution: Vector Clocks

10. Basic put() C B A G F DE H Coordinator k:v ([G, 1]) N = 3, W = 2

11. get() with Sloppy Quorum C B A G F DE H Coordinator k? N = 3, W = 2, R = 2 k:v ([G, 1]) k:v ([G, 1])

12. Takeaway: Tunable! Change N,R,W for desired consistency, availability

13. Antientropy: Merkle Trees Object hashes at leaves Hash of children Node ANode B

14. More Ideas Hinted handoff Explicit join/leave mechanism (gossip-based) Seed nodes Local notion of failure

15. Comments

16. System Scope “…the system needs to have scalable and robust solutions for load balancing, membership and failure detection, failure recovery, replica synchronization, overload handling, state transfer, concurrency and job scheduling, request marshaling, request routing, system monitoring and alarming, and configuration management.”

17. Triggers Client registers to be notified when key changes Challenging with eventual consistency! Solution: sloppy triggers

18. Setting N,R,W …is annoying! Can we auto-configure R? What about W?

19. Supporting Multiple N,R,W Different availability/consistency tradeoffs for each object …without making multiple systems