Consistency Models

Consistency models define the ordering and visibility guarantees that a distributed system provides for reads and writes. They describe what values a client may observe when multiple replicas process operations concurrently or with delay.

In a distributed system, replicas can temporarily hold different states because writes take time to propagate. A consistency model specifies which observations are allowed, rather than requiring every replica to return the same value immediately.

Strong consistency provides a tight relationship between completed writes and subsequent reads. Linearizability is a common strong model: each operation appears to take effect atomically at some point between its invocation and response, while preserving real-time ordering for non-overlapping operations.

Weaker models allow more behaviors in exchange for availability, lower latency, or reduced coordination. Eventual consistency means that if updates stop and communication continues, replicas eventually converge, but a read may temporarily return an older value.

Causal consistency preserves the ordering of causally related operations. For example, if one write is made after observing another write, a client should not observe the dependent write without also being able to observe its cause. Unrelated concurrent operations may still be observed in different orders.

In Java backend systems, consistency decisions often appear around databases, caches, message brokers, and replicated services. Idempotency complements consistency: an idempotent operation can safely be retried, but idempotency by itself does not make replicated reads immediately consistent.

Key points

• Consistency specifies which read/write observations are permitted across replicas.
• Linearizability preserves real-time ordering and makes operations appear atomic.
• Eventual consistency permits stale reads but requires convergence after updates stop.
• Causal consistency preserves ordering between causally related operations.
• Idempotency makes retries safe; it is separate from replica-consistency guarantees.

Interview questions

What does consistency mean in a distributed system?

Consistency is a contract about what values and operation order a client can observe. With multiple replicas, different nodes may temporarily have different state. A consistency model defines which such observations are valid. Stronger models require more coordination or impose stricter ordering guarantees.

What is linearizability, and how is it different from eventual consistency?

Linearizability makes each operation appear to occur atomically at a single point between its invocation and response. It also preserves real-time ordering when operations do not overlap. Eventual consistency allows a read to observe an older state while replicas converge. Therefore, eventual consistency permits observations that linearizability would reject.

What is causal consistency?

Causal consistency preserves the ordering of operations when one operation could have influenced another. For example, if a client reads a post and then writes a comment based on that post, another client should not observe the comment without the corresponding causal history. Operations that are concurrent and unrelated do not necessarily need a single global order. This can provide useful semantics with less coordination than a globally ordered model.

How does consistency interact with retries and idempotency?

Idempotency controls the effect of repeating the same logical request, while consistency controls what clients can observe across replicas. A payment request can therefore be idempotent even if a subsequent read temporarily reaches a replica with stale data. Safe retries usually require a stable idempotency key or equivalent request identity. The two mechanisms solve different failure modes and are often used together.

How would you choose a consistency model for a replicated Java service?

I would start with the application's correctness requirements rather than selecting a model by default. Operations that require immediate, globally ordered visibility may need a strong guarantee, while feeds or analytics may tolerate stale data and use weaker consistency. I would then consider latency, availability, network partitions, geographic distribution, and coordination costs. The chosen guarantee should be explicit in the API and tested with failure scenarios.