When "Worst" is Best in Distributed Systems

When "Worst" is Best in Distributed Systems

Strange Loop Conference via YouTube Direct link

Tail Latency in (Micro)services

13 of 16

13 of 16

Tail Latency in (Micro)services

Class Central Classrooms beta

YouTube playlists 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. 1 Intro
  2. 2 What if we designed computer systems for worst case scenarios?
  3. 3 Designing for the worst case often penalizes the average case
  4. 4 Distributed Systems Matter
  5. 5 Networks make design hard
  6. 6 Handling Worst-Case Net Behavior availability addresses delays, drops
  7. 7 DISTRIBUTED TRANSACTIONS (EC2)
  8. 8 But wait! What about CAP?!?!
  9. 9 "Worst" is a Design Tool Example: Coordination-Avoiding Databases
  10. 10 Simple Example: Read Committed
  11. 11 Punchline: Distributed Systems & Networks
  12. 12 Fail-over helps (Dev)Ops
  13. 13 Tail Latency in (Micro)services
  14. 14 Universal Design
  15. 15 This talk: When can designing for the worst case improve the average case?
  16. 16 Reasoning about worst-case scenarios can be a powerful design tool

Never Stop Learning.

Get personalized course recommendations, track subjects and courses with reminders, and more.

Someone learning on their laptop while sitting on the floor.