32-bit vs 64-bit
    Annotations vs Decorators
    BigQuery vs Bigtable
    Block Storage vs File Storage vs Object Storage
    C vs C++
    Canvas vs SVG
    Constructor vs Init() vs Factory
    Containers vs Virtual Machines (VMs)
    DOM vs Virtual DOM vs Shadow DOM
    DQL vs DDL vs DCL vs DML
    Dagger vs Guice
    Data Mining vs Machine Learning vs Artificial Intelligence vs Data Science
    Flux vs Redux
    GCP API Gateway vs Cloud Endpoint
    GCP Cloud Run vs Cloud Functions vs App Engine
    GCP DataFlow vs Dataproc
    Google Analytics 4 vs Universal Analytics
    Google Internal vs Open Source
    HEIC vs HEIF vs HEVC vs JPEG
    Java vs C++
    Jetty vs Netty
    Kotlin vs Java
    LLVM vs JVM
    Linux vs BSD
    Microcontroller vs Microprocessor vs Computer
    Node.js vs Erlang
    POSIX vs SUS vs LSB
    Pass-by-value vs Pass-by-reference
    Proto2 vs Proto3
    PubSub vs Message Queue
    REST vs SOAP
    React vs Flutter vs Angular
    Rust vs C++
    SLI vs SLO vs SLA
    SRAM vs DRAM
    SSD vs HDD
    Software Engineer vs Site Reliability Engineer
    Spanner vs Bigtable
    Stack based VM vs Register based VM
    Stateless vs Stateful
    Static Site Generation vs Server-side Rendering vs Client-side Rendering
    Strong Consistency vs Eventual Consistency
    Subroutines vs Coroutines vs Generators
    Symlinks vs Hard Links
    Tensorflow vs PyTorch
    Terminal vs Shell
    Vi vs Vim vs gVim vs Neovim
    WAL vs rollback journal
    gtag vs Tag Manager
    stubs vs mocks vs fakes

Strong Consistency vs Eventual Consistency

Updated: 2022-02-12

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