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

Like this? Share it with your network

Share

Webinar: Eventual Consistency != Hopeful Consistency

  • 1,009 views
Uploaded 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.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,009
On Slideshare
1,008
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
3
Comments
0
Likes
0

Embeds 1

http://tweetedtimes.com 1

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!