Consistency Models

Consistency models specify which read and write outcomes a distributed system permits. Strong, eventual, session-level, and causal guarantees differ in ordering, visibility, and coordination costs, so choose based on the application's invariants and tolerance for stale data.

A consistency model defines what values clients may observe when a system has multiple copies of data or serves concurrent operations. It is a contract for application behavior, not simply a statement that replicas are synchronized or that data is correct.

Strong consistency is commonly used to describe behavior where reads reflect completed writes across clients, but the exact guarantee matters. Linearizability is a precise example: each operation appears to take effect at one instant between its start and completion, and real-time ordering of non-overlapping operations is respected. Strong guarantees can require coordination, which may increase latency or reduce availability during network failures.

Eventual consistency allows a read to return an older value while updates propagate. If updates stop and the system continues making progress, replicas are expected to converge. This does not, by itself, promise a maximum staleness duration, a particular ordering of concurrent updates, or that a client immediately sees its own write.

Applications can also rely on narrower guarantees. Read-your-writes ensures a client sees its own completed writes in later reads; monotonic reads prevent that client from moving backward to older observed state. Causal consistency ensures that operations linked by cause and effect are observed in a compatible order, while leaving concurrent operations less constrained.

Choosing a model depends on the operation and user experience. A product may tolerate stale analytics but require read-your-writes for profile edits, or require strong coordination for inventory reservations. State the required invariant, the scope (such as one session or all clients), and acceptable latency and failure behavior before choosing a database or replication strategy.

Key points

• A consistency model defines the read and write behaviors clients are allowed to observe.
• Linearizability is a precise real-time ordering guarantee; “strong consistency” may be used less precisely.
• Eventual consistency allows temporary stale reads and does not inherently bound staleness.
• Read-your-writes and monotonic reads are session-level guarantees, not global agreement.
• Causal consistency preserves cause-and-effect order while allowing concurrency.

Interview questions

What is a consistency model, and why should a backend engineer care about it?

A consistency model specifies which outcomes are allowed when clients read and write data in a distributed system. It matters because applications can otherwise depend on behavior the storage layer does not guarantee. For example, a user may expect a profile edit to appear immediately even if replicas update asynchronously. The model helps balance correctness requirements against latency, coordination, and behavior during failures.

What does eventual consistency guarantee, and what does it leave unspecified?

Eventual consistency allows clients to observe stale values while updates are being propagated. Its convergence promise applies if updates stop and the system continues to make progress. It does not inherently promise that replicas converge within a fixed time, or that a client immediately reads its own write. It can suit data such as analytics or feeds when temporary inconsistency is acceptable.

Compare linearizability with eventual consistency.

Linearizability requires each operation to appear to take effect at a point between its invocation and response, while preserving real-time order for non-overlapping operations. Eventual consistency permits temporary divergent observations and only promises convergence under its stated progress conditions. Linearizability is therefore much stronger, but it can require coordination across nodes and may cost latency or availability under network partitions. The right comparison depends on the precise guarantees an application needs.

How does read-your-writes consistency work, and how might a service provide it?

Read-your-writes ensures that after a client completes a write, its subsequent reads reflect that write or a later value. A system might implement this by routing the session to a suitable replica, tracking a write version and waiting until a replica has caught up, or reading from the primary. These approaches have different latency and availability implications. The guarantee is scoped to a client or session and does not mean every other client immediately sees the write.

What does causal consistency add, and what does it not guarantee?

Causal consistency preserves the order of operations when one could have influenced another, such as reading a post and then commenting on it. Concurrent operations with no causal relationship may still be observed in different orders. Eventual consistency alone does not require causal ordering, although a system may offer both convergence and causal guarantees. Causal consistency is useful when preserving cause-and-effect relationships matters but a single global order is unnecessary.