Anti-Pattern: Optimistic Consistency
Vlad Khononov
💡Creator of the Balanced Coupling model 🎤 Keynote Speaker ✍️ O'Reilly and Pearson Author: "Balancing Coupling in Software Design" and "Learning Domain-Driven Design" 📚
Ladies and Gentlemen, lo and behold a new consistency model - “Optimistic Consistency”. Implementation of this pattern is quite simple: commit as many transactions as you want, against as many storage mechanisms as you need. That’s all. Let’s see an example.
Example
Say as the result of some user’s operation the system has to:
- Modify data in MongoDB
- Publish some events to Kafka
- Update search model in Elasticsearch; and
- Execute an operation on some remote system
You implement this logic by executing those operations one after another. Simple and elegant. After all, why over-engineer? Everything will be just fine, namely:
- Servers will always be up
- Network is the most reliable thing on earth
- Your process will only be shut down gracefully …like, why would anyone stop it in the middle of execution, right?
In addition to simplicity of implementation, this approach brings multiple additional benefits.
Advantages of Optimistic Consistency
The main advantage is that you can always promise strong consistency. Without the hassle of actually ensuring it. If someone will ever question the systems consistency, always use eventual consistency as an excuse. After all, we are living in the brave new world of distributed systems, right?
Optimistic consistency brings another huge benefit. In the *very unlikely * scenario of something indeed going wrong, you can always refer the extremely low percentage of such possible issues. Like, who will ever notice if the system looses a transaction or two???
Ok, seriously now
Hope is not a strategy and optimistic consistency is nothing but negligence. Things will go wrong: systems will crash, network will be partitioned, and occasionally, servers’ plugs will be pulled. It cannot be called “eventual consistency”, but rather “eventual inconsistency”.
Claiming that no one will ever notice such corruption just emphasizes how big of an issue this is - the system will be silently corrupting data, but “no one will ever notice”!
Please don’t do it.
How to handle such scenarios? Read Jimmy Bogard’s awesome “Life Beyond Distributed Transactions” series.
Check out my blog for my other posts on software architecture, domain-driven design, and microservices: vladikk.com
Web Developer | Next.js | React.js | Typescript
1yGreat article If I have a simple state change for the data after let's say a form-submit/fetch/mutation, what is your opinion about the following? - Updating the data after the success of the form-submit/fetch/mutation. - Re fetching the data after the success of the form-submit/fetch/mutation.