Eventual Consistency Explained for Non-techies
If you work in the Computer industry, especially the Internet industry, chances are good that you have encountered an eventually-consistent system.
For example, when managing an internet or IT business, you might have considered one of all of the following DB architectures:
- Use a single DB host
- e.g. MyHost
- Use a single DB host for your writes, but several for your reads
- e.g. MyWriteHost & MyReadHost1, MyReadHost2, MyReadHost 3, etc …
- Use multiple DB hosts
- e.g. MyHost1, MyHost2, etc….
- Use multiple DB hosts for your writes and your reads
- e.g. MyWriteHost1, MyWriteHost2, etc… & MyReadHost1, MyReadHost2, etc, ….
These 4 choices represent an increasing degree of data traffic partitioning, with 1 having no partitioning and 2 having the most partitioning.
In most eCommerce sites, the DB read traffic dwarfs the DB write traffic, typically 10-to-1. In such cases, architecture 2 makes a lot of sense. For example, a user might change his phone number from 555-5555 to 666-6666. 666-6666 will be written to MyWriteHost. An asynchronous back-ground task will copy data from MyWriteHost to MyReadHost1 (for example) after a brief delay, also known as the Inconsistency Window. If the website tries to read the latest phone number from MyReadHost1, it will still see 555-5555 until the Inconsistency (time) Window expires. This is an eventually-consistent system.
This is known as a read-write split architecture - companies like eBay heavily leverage such an architecture. Read-write split architectures are eventually-consistent.
Another use-case that exhibits eventual-consistency is seen in Amazon’s SimpleDB. Such a system is actually an Active-Active HA storage system. Each node can fail-over to any other node and nodes are kept in sync by an asynchronous background thread.
- rooksfury posted this