Understanding Sequential, Causal, and Eventual Consistency Models

In previous posts we briefly described several consistency models and their significance for database transactions. In this article we aim to close the knowledge gap by explaining other well‑known models such as eventual and causal consistency, which are more common in distributed systems than in traditional databases.

Sequential Consistency

Recall the consistency model we created last time that follows the correct path.

Thus we assume that the descendants of the serializable model are not as frightening as the first one. Today the sequential consistency model (the left‑hand path in the image) will be unveiled.

First, let’s become familiar with the sequential model itself. Lamport defines it as the property:

All processes see the same result, as if read and write operations occur in some order, and each processor’s operations appear in that sequence in the order specified by its program.

To make this more intuitive, imagine independent clients (e.g., CPUs or threads) accessing a shared resource (e.g., RAM or a distributed file system). The consistency model describes the contract between the system and its users: what users can expect and what state the system must be in during interaction.

Consider two processes P1 and P2. P1 reads R(x) (red), then writes W(x) (blue), then writes W(y) (green). P2 reads R(y) (red), then reads R(x) (blue), then writes W(y) (green).

If the system claims to be strictly serializable, it must present a global order where all operations appear in the same order for every process, often requiring a global clock.

The system guarantees that the red read of P1 occurs before the blue write, which occurs before the green write, and that P2’s red read occurs before P1’s red read—so all events are ordered.

When the system is only sequentially consistent, the per‑process order is preserved, but the total order is not guaranteed; the system may interleave operations arbitrarily:

Thus each process sees its own operations in program order, but the global order can differ, allowing more flexibility and easier implementation without a global clock.

Causal Consistency

Having understood sequential consistency, let’s relax the requirements. Causal consistency guarantees only that causally related operations appear in order; unrelated operations may be seen in different orders by different clients.

For example, if process P1 writes value 1 to x, then P2 reads x (seeing 1), performs some computation, and writes value 3 to x, the two writes are causally related and must be observed in the same order by all processes. If another process reads 1 then 3, the order is respected; if it reads 3 then 1, the system violates causal consistency.

Unrelated writes can be observed in any order. The following diagram shows two independent writes to x that have no causal relationship.

A human‑friendly example is a comment thread: a reply must appear after the comment it answers, preserving causal order, while unrelated comments may be reordered.

Eventual Consistency

Simply put, eventual consistency guarantees that if no new updates occur, all clients will eventually see the same system state. It is a weak guarantee that is easy to implement and offers high performance.

Several client‑centric session guarantees implement eventual consistency:

Monotonic Reads (MR) : once a value is read, all subsequent reads return that value or a newer one.

Monotonic Writes (MW) : writes are applied in the order they were issued.

Read Your Writes (RYW) : after a client updates a data item, any subsequent read of that item returns the updated value.

Pipelined RAM (PRAM) : all operations of a single process are seen by others in the order they were executed.

Writes Follow Reads (WFR) : a write that follows a read is only visible after the read’s effect is visible.

These guarantees together realize eventual consistency.

Conclusion

The colored regions in the guiding diagram indicate availability: red regions cannot be fully available due to network partitions; green regions are highly available with weak guarantees; blue regions represent sticky‑available systems where a client’s operations eventually see a consistent state. More details can be found in Peter Bailis’s paper.

Thank you for following, sharing, and liking this article.