Database Consistency Patterns
If the data is spread throughout the database in different tables and servers. We would have to update the new value of an entity everywhere. This is troublesome and things can get inconsistent.
Database Consistency means that every read must have the latest write or an error.
After write, read may or may not see the latest write.
This approach is seen in systems such as memcached. Works well in realtime usecase like VOIP, Video Calls, Multiplayer Games etc. For example, if you are on a phone call and lose reception for a few seconds, when you regain connection you do not hear what was spoken during connection loss.
After the write, the read will eventually see the latest updated value. Eventual consistency is a consistency model which enables the data store to be highly available. It is also known as optimistic replication & is key to distributed systems.
So, we have many datastore nodes spread across the world which the micro-blogging site uses for persisting data.
Since there are so many nodes running, there is no single point of failure. The data store service is highly available. Even if a few nodes go down the persistence service as a whole is still up.
If the data is updated in one region all the other regions at present see the old value and not the latest updated value until it is eventually updated in all regions. So, the data was initially inconsistent but eventually got consistent across the server nodes deployed around the world. Amazon S3, SQS and Simple DB are example of eventual consistency.
After a write, reads will see it. Data is replicated synchronously.
All the server nodes across the world should contain the same value of an entity at any point in time.
The only way to implement this behaviour is by locking down the nodes when being updated. All the nodes across different geographical zones have to be locked down to prevent any concurrent updates. The value gets replicated globally across all nodes. Once all the nodes reach a consensus, the locks get lifted.
In order to get Strong Consistency it impacts the Availability based on CAP theorem but benefits Consistency in CAP theorem.
Distributed Transaction (Strong Consistency in Distributed System) and Distributed Locks will help you better understand ways to achieve strong consistency.