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

Webinar: Eventual Consistency != Hopeful Consistency

on

  • 810 views

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.

Statistics

Views

Total Views
810
Views on SlideShare
809
Embed Views
1

Actions

Likes
0
Downloads
3
Comments
0

1 Embed 1

http://tweetedtimes.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Webinar: Eventual Consistency != Hopeful Consistency Webinar: Eventual Consistency != Hopeful Consistency Presentation Transcript

  • Eventual Consistency != Hopeful Consistency Embracing Optimistic Design in the Persistence Layer
  • Who am I? Christos Kalantzis Netflix Inc. Engineering Manager – Cloud Database Engineering @chriskalan ckalantzis@netflix.com www.linkedin.com/in/christoskalantzis
  • 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
  • • C* has tunable consistency – All – Quorum – One C* Replication & Consistency Recap
  • 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
  • Remember When…? • Slaves could lose transactions
  • Remember When…? • No “Repair” function
  • Remember When…? • We trusted it • We still trust it
  • 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”
  • 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!
  • Netflix Experiment
  • 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
  • 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
  • Low Consistency Example 1 Retail
  • Low Consistency Example 2 Banking
  • 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
  • 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
  • Q&A
  • Thank you!