What is Eventual Consistency, and how is it different from Strong Consistency?

ScyllaDB
, , ,
1

Can you please provide information on Eventual Consistency and how exactly it differs from Strong Consistency?

2

It’s a big topic, and I’ll try to answer it and give an overview. Check the links below to learn more.

To understand the difference, I’ll start with defining consistency.

In Database Management Systems, consistency (sometimes also called correctness) means that after a successful write (or update or delete) request of a value, any read request receives the latest value.

Another way to understand it is that any given database transaction can only change the affected data in allowed ways. Any written data has to be valid according to the defined rules, constraints, and triggers.

Consistency is one of the guarantees defined in relational, transactional databases. These provide ‘ACID guarantees’ and are sometimes called strongly consistent databases. There are ambiguities in the definition of these guarantees. One definition for ACID transactions is:

  • Atomicity: If any part of the transaction fails, the entire operation rolls back.
  • Consistency: The database remains structurally sound with every transaction.
  • Isolation: Each transaction is independent of other transactions.
  • Durability: All transaction results are permanently preserved.

ACID compliance is a complex and often contested topic. Delivering the consistency guarantee is incredibly difficult in a globally distributed database topology involving multiple clusters, each containing many nodes.

For this reason, ACID-compliant databases are usually slower, more rigid, and difficult to scale. Since SQL databases are all ACID compliant to varying degrees, they also share these downsides.

Some relational database systems enable ACID guarantees to be relaxed to offset these downsides.

In contrast to SQL’s ACID guarantees, NoSQL databases provide BASE guarantees:

  • Basic Availability: Data is available most of the time, even during a partial system failure.
  • Soft state: Replicas are not consistent all the time.
  • Eventual consistency: Data will become consistent at some point in time, with no guarantee when.

The above is also related to the CAP theorem, which states that in a distributed data system, only two out of the following three guarantees can be satisfied:

  • Consistency: The same response is given to all identical requests
  • Availability: Requests receive responses even during a partial system failure
  • Partition Tolerance: Operations remain intact even when some nodes are unavailable.

An extension to the CAP theorem, originally coined by Dr. Daniel Abadi, is the PACELC theorem. This theorem states that in case of partitioning (P) in a distributed system, a choice has to be made between Availability (A) and Consistency (C).

ScyllaDB, Apache Cassandra, Amazon DynamoDB, and other NoSQL databases sacrifice a degree of consistency to increase availability. Rather than providing strong consistency, they provide eventual consistency. This means that in some cases, a read request will fail to return the result of the latest WRITE.

In ScyllaDB (and Apache Cassandra), consistency is tunable. For a given query, the client can specify a Consistency Level, which refers to the number of replicas required to respond to a request for it to be considered successful. This is also known as Tunable Consistency.

A related feature is Lightweight Transactions (LWT). LWT in ScyllaDB allow the client to modify data based on its current state: that is, to perform an update that is executed only if a row does not exist or contains a certain value.

LWT are limited to a single conditional statement, which allows an “atomic compare and set” operation. That is, it checks if a condition is true, and if so, it conducts the transaction. If the condition is not met, the transaction does not go through.

Further reading: