V. Tailor Consistency
Individualize consistency per component to balance availability and performance
Consistency is about guaranteeing the correctness and integrity of your application and user’s data. Providing more consistency guarantees than you actually need will not add value and will only decrease the availability, efficiency, and performance of your application. It doesn’t matter if you are correct if you can’t serve your customers reliably.
A helpful way to think about convergence in distributed systems is that the system is always in the process of convergence but never manages to fully “catch up” and reach a final state of convergence (on a global system scale). This is why it is so important to carefully define your “units of consistency”—small islands of strong consistency in a river of constant change and uncertainty—that can give you some level of predictability and certainty.
When possible, design systems for eventual consistency or causal consistency, leveraging asynchronous processing, which tolerates delays and temporary unavailability of its participants (e.g. using an event-driven architecture, certain NoSQL databases, and CRDTs ). This allows the system to stay available and eventually converge, and in the case of failure, automatically recover.
If strong consistency is inherently needed for the correctness of a use-case, it should be applied judiciously and selectively, with clearly defined consistency boundaries, keeping the unit of consistency as small as possible to retain a maximum of scalability and availability.