This week on Mobycast, Jon and Chris conclude their multi-part series on "database soup", where we make sense of the jumbled acronyms of consistency models.
In this episode, we learn about eventual consistency and the BASE properties. Eventual consistency may sound like a beer guy meme - "I am not always consistent, but when I am, I get there eventually.". But it's no joke - eventual consistency is a key technique for scaling systems, and it's important to know what it is and when to use it.
We finish up by summarizing what we have learned about ACID and BASE and knowing the tradeoffs each makes. Afterwards, you'll no longer confuse consistency models with the pH scale of your high school chemistry class.
- In this new series, we are discussing database consistency models explained in three acts. This episode is "Act III: Eventual consistency saves the web (circa early 2000s)".
- We explain eventual consistency and the motivation behind the philosophy.
- The BASE acronym stands for three key properties of a distributed system that utilizes eventual consistency. We define and explain these BASE attributes:
- Basically available
- Soft state
- Eventual consistency
- We share the story of Werner Vogel's keynote at re:Invent 2018, where he outlined the reasons why DynamoDB was created. In particular, DynamoDB allows for an eventual consistency data model.
- Interestingly, the DynamoDB story closely parallels what happened when Chris was at Microsoft. It just happened at least 6 years earlier.
- We then wrap up everything we have learned about ACID, CAP, and BASE by providing some guidelines on when to choose ACID vs. BASE systems.
Detailed Show Notes
What is Mobycast?
A Podcast About Cloud Native Software Development, AWS, and Distributed Systems