Designing Data-Intensive Applications – Leaderless Replication

We wrap up our replication discussion of Designing Data-Intensive Applications, this time discussing leaderless replication strategies and issues, while Allen missed his calling, Joe doesn't read the gray boxes, and Michael lives in a future where we use apps.

If you're reading this via your podcast player, you can find this episode's full show notes at https://www.codingblocks.net/episode162. As Joe would say, check it out and join in on 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

Do you have TikTok installed?

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

News

• Thank you for the latest review!
  • iTunes: tuns3r

Check out the book!

Single Leader to Multi-Leader to Leaderless

• When you have leaders and followers, the leader is responsible for making sure the followers get operations in the correct order
• Dynamo brought the trend to the modern era (all are Dynamo inspired) but also…
  • Riak
  • Cassandra
  • Voldemort
• We talked about NoSQL Databases before:
  • Episode 123 Data Models: Relational vs Document
• What exactly is NewSQL? https://en.wikipedia.org/wiki/NewSQL
• What if we just let every replica take writes? Couple ways to do this…
  • You can write to several replicas
  • You can use a coordinator node to pass on the writes
• But how do you keep these operations in order? You don't!
  • Thought exercise, how can you make sure operation order not matter?
  • Couple ideas: No partial updates, increments, version numbers

Multiple Writes, Multiple Reads

• What do you do if your client (or coordinator) try to write to multiple nodes…and some are down?
• Well, it's an implementation detail, you can choose to enforce a "quorom". Some number of nodes have to acknowledge the write.
  • This ratio can be configurable, making it so some % is required for a write to be accepted
  • What about nodes that are out of date?
  • The trick to mitigating stale data…the replicas keep a version number, and you only use the latest data – potentially by querying multiple nodes at the same time for the requested data
  • We've talked about logical clocks before, it's a way of tracking time via observed changes…like the total number of changes to a collection/table…no timezone or nanosecond differences

How do you keep data in sync?

• About those unavailable nodes…2 ways to fix them up
  • Read Repair: When the client realizes it got stale data from one of