MyDistributed.Systems

This is the second part of a two-part post on eventual consistency and the problem of conflict resolution. In the  first part , we focused on the definition of the eventual consistency, its sufficient conditions, and conflict resolution using physical and logical clocks. We saw each method has its problems. In this part, we will see how we can solve these issues and provide eventual consistency with better conflict resolution. Listen to the Audio Blog Conflict Resolution using Vector Clocks The good thing about physical clock timestamps is that they carry information related to the real-time order of events, e.g., if we write v2, one minute after writing v1, the physical timestamp of v2 will be most likely larger than that of v1, assuming we have reasonable clock synchronization in place. However, physical clocks are not 100% accurate. Thus, due to clock synchronization errors, the timestamps may not reflect t

Eventual consistency is one of the defining characteristics of many modern data stores. By getting rid of strong consistency and embracing eventual consistency, service providers can keep their services available even when replicas cannot talk to each other. Eventual consistency also removes the performance bottlenecks of strong consistency and lets us scale the system much more easily. Due to its significant benefits, eventual consistency has been widely adopted in the industry. Every day, when you are using social networks, shopping online, or even when you are doing online banking, most likely you are using services that rely on eventual consistency.