Designing Data-Intensive Applications – Multi-Leader Replication

We continue our discussion of Designing Data-Intensive Applications, this time focusing on multi-leader replication, while Joe is seriously tired, and Allen is on to Michael’s shenanigans.

For anyone reading this via their podcast player, this episode’s show notes can be at https://www.codingblocks.net/episode161, where you can join the conversation.

Sponsors

• Educative.io – Learn in-demand tech skills with hands-on courses using live developer environments. Visit educative.io/codingblocks to get an additional 10% off an Educative Unlimited annual subscription.

Survey Says

How do you put on your shoes?

Take the survey at: https://www.codingblocks.net/episode161.

News

• Thank you very much for the new reviews:
  • iTunes: GubleReid, tbednarick, JJHinAsia, katie_crossing
  • Audible: Anonymous User, Anonymous User … hmm

When One Leader Just Won’t Do

Talking about Multi-Leader Replication

Replication Recap and Latency

• When you’re talking about single or multi-leader replication, remember all writes go through leaders
• If your application is read heavy, then you can add followers to increase your scalability
• That doesn’t work well with sync writes..the more followers, the higher the latency
  • The more nodes the more likely there will be a problem with one or more
  • The upside is that your data is consistent
• The problem is if you allow async writes, then your data can be stale. Potentially very stale (it does dial up the availability and perhaps performance)
• You have to design your app knowing that followers will eventually catch up – “eventual consistency“
  • “Eventual” is purposely vague – could be a few seconds, could be an hour. There is no guarantee.
• Some common use cases make this particularly bad, like a user up