Your SlideShare is downloading. ×
Webinar: Eventual Consistency != Hopeful Consistency
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Webinar: Eventual Consistency != Hopeful Consistency

1,173

Published on

This session will address Cassandra's tunable consistency model and cover how developers and companies should adopt a more Optimistic Software Design model.

This session will address Cassandra's tunable consistency model and cover how developers and companies should adopt a more Optimistic Software Design model.

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,173
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Eventual Consistency != Hopeful Consistency Embracing Optimistic Design in the Persistence Layer
  • 2. Who am I? Christos Kalantzis Netflix Inc. Engineering Manager – Cloud Database Engineering @chriskalan ckalantzis@netflix.com www.linkedin.com/in/christoskalantzis
  • 3. C* Replication & Consistency Recap • C* is eventually Consistent – That means it WILL get there…eventually • Eventually is not: – A day from now – A minute from now – A second from now • In most cases it is milliseconds
  • 4. • C* has tunable consistency – All – Quorum – One C* Replication & Consistency Recap
  • 5. Remember When...? • In early 2000s, Read was scaled out by adding replication Slaves to a Master DB. • Writes went to a single Master, Reads went to Slaves
  • 6. Remember When…? • Slaves could lose transactions
  • 7. Remember When…? • No “Repair” function
  • 8. Remember When…? • We trusted it • We still trust it
  • 9. C* Consistency Concerns • “I want high consistency in my Reads/Writes just like I had in my RDBMS setup” – You never really had it. • “I want my DB to catch integrity issues” – We’ve been turning FK off for years! • See Rails, Grails & other MVC frameworks • Can I trust that C* will replicate my data when writing at CL 1”
  • 10. Netflix Experiment • Created a multi-datacenter C* 1.1.7 cluster of 48 nodes in each DC • Put load on C* Cluster – 100K total operations per second (50 K in each DC) • Wrote 1,000,000 records at CL1 in one DC • Read same 1,000,000 records at CL1 in other DC • ALL records were read successfully • You can trust it!
  • 11. Netflix Experiment
  • 12. Optimistic vs. Pessimistic Design • Pessimistic Design – Design with high consistency, you punish your users 99.9% of the time • Higher consistency = higher latency • Diminished user experience
  • 13. Optimistic vs. Pessimistic Design • Optimistic Design – Trust your data store • Know your business and your application – Always ask yourself, is it really that important? • Handle edge cases through contingency plans
  • 14. Low Consistency Example 1 Retail
  • 15. Low Consistency Example 2 Banking
  • 16. Hurdles Faced • Engineers are stubborn! – 1+1=2 .. not eventually 2 • Middle management is scared – It’s a feat you convinced them to use C* – Now you got to convince them to accept low consistency? • Engaging Product team to implement some type of contingency plans
  • 17. How to Overcome those Hurdles • Prove it through a POC • Show them the benefits of an improved user experience – Its all about the user • You may be working for the wrong company – We’re hiring! – jobs.netflix.com
  • 18. Q&A
  • 19. Thank you!

×