Strong Consistency vs Eventual Consistency
Strong consistency is enforcing the traditional relational database's concept of "transactions" in a distributed system, everyone should see the same data everywhere, before that is fully synchronized it's willing to sacrifice some availability, so it's a CP system in CAP theorem.
Eventual consistency on the other hand make it always available to write but does not guarantee reading from different node will always return the same value. So it's an AP system.
Intuitively strongly consistent systems should be used in mission critical scenarios, like payment or trading, while eventually consistent systems are good for high volume but non-critical cases, like leaving a comment but not immediately visible to everybody.
Eventual consistency was popularized by Google's BigTable and Facebook's Cassandra. But BigTable is being replaced by Spanner, a strongly consistent SQL database; and Cassandra is no longer being used by Facebook(however Instagram still uses it), the main store is MySQL using RocksDB as the engine, plus TAO as the cache layer.
So is eventual consistency dead? Probably not, or not yet. It still has its use cases, Google Cloud Platform provides both Cloud Spanner and Cloud BigTable, other companies still use Cassandra(however its db-engines ranking had been dropping down). Strong consistency is indeed easier to use and less error prone, if it can magically solve the latency issue, eventual consistency may not be necessary. Spanner claims to be the impossible both consistent and available, i.e. a CAP system, no compromises, contrary to CAP theorem, that is still wait to be proved.
Strong Consistency
- pros
- synchronized updates
- consistent under partition(CP)
- appealing for users and programmers
- safe
- cons
- expensive
- unavailable in case of network failure
- slow
Eventual Consistency
- pros
- fast and responsive
- available under partition(AP)
- replicated close to users
- cons
- updates delivered in a mess
- arbitrary reconciliation(e.g. last writers wins)
- application programmer must compensate for DB imperfections
- complex, bug-prone