I think the author describes a heterogeneous distributed system with no shared transactional space (db and search engine and cache and olap etc). In this case, if you have a transactional database as a source of truth then you can enforce that truth upon the rest of the system (article considers different ways of doing so), but because of delays and occasional hiccups it can't be fully consistent. With that view I agree.
However if the question is whether you want a consistent transactional storage as the core of the system, or an eventually consistent storage would do, then for me the answer is 100% for consistent storage at the core. Systems built around eventually consistent storage can go to hell.
I once worked with an engineer who considered all TTL-enabled storages to be eventually consistent: if you leave it alone for a while all replicas eventually go down to zero.
8 comments
[ 1.5 ms ] story [ 32.2 ms ] threadCan't you, though, if you sacrificed availability?
I like to think "Eventual Consistency" is an euphemism for no consistency, mostly popularized by the MongoDB folks.
In my opinion it is not a coincidence that the term was almost unknown before 2009, the year MongoDB was introduced.
https://trends.google.com/trends/explore?date=all&q=%22event...
However if the question is whether you want a consistent transactional storage as the core of the system, or an eventually consistent storage would do, then for me the answer is 100% for consistent storage at the core. Systems built around eventually consistent storage can go to hell.