Completed
Designing for the worst case often penalizes the average case
Class Central Classrooms beta
YouTube videos curated by Class Central.
Classroom Contents
When "Worst" is Best in Distributed Systems
Automatically move to the next video in the Classroom when playback concludes
- 1 Intro
- 2 What if we designed computer systems for worst case scenarios?
- 3 Designing for the worst case often penalizes the average case
- 4 Distributed Systems Matter
- 5 Networks make design hard
- 6 Handling Worst-Case Net Behavior availability addresses delays, drops
- 7 DISTRIBUTED TRANSACTIONS (EC2)
- 8 But wait! What about CAP?!?!
- 9 "Worst" is a Design Tool Example: Coordination-Avoiding Databases
- 10 Simple Example: Read Committed
- 11 Punchline: Distributed Systems & Networks
- 12 Fail-over helps (Dev)Ops
- 13 Tail Latency in (Micro)services
- 14 Universal Design
- 15 This talk: When can designing for the worst case improve the average case?
- 16 Reasoning about worst-case scenarios can be a powerful design tool