Concrete scenario
A user updates a profile, then reads through another replica while a friend reads concurrently.
Mechanics
Linearizability makes each operation appear atomic between invocation and response and respects real-time precedence for completed operations. Sequential consistency preserves one order consistent with each client program order but not real time. Causal and session guarantees constrain only related operations or one client view. Implementations may use a leader, quorum protocol, or another serialization mechanism.
Failure mode
Replica lag can violate read-your-writes; failover can move a client to an older view; concurrent updates can be observed in different orders under weaker models. A majority partition may continue while a minority rejects operations.
Trade-off
Stronger guarantees simplify application reasoning but add coordination latency and can reduce availability during faults. Weaker guarantees improve locality and fault tolerance only if the product can reconcile stale or concurrent results.
Worked example: the profile-photo bug
Alice changes her profile photo. The write goes to the leader in us-east, and replication to the eu-west replica lags by 800 ms. Alice refreshes 200 ms later and her request is routed to eu-west.
- Eventual consistency: she sees her old photo and thinks the upload failed. Allowed, but a bad experience.
- Read-your-writes (a session guarantee): the client remembers the log position or timestamp of her write, and the replica waits until it has caught up to that point, or the request is sent to the leader. She sees the new photo, while other users may still see the old one for 800 ms, which nobody notices.
- Linearizability: every reader, including her friend Bob, is guaranteed the new photo once the write has been acknowledged. That requires every read to go through the leader or a quorum, adding a cross-region round trip of about 80 ms to every photo read.
For profile photos, read-your-writes is the right choice. For "is this username taken?" you need linearizability, or a uniqueness constraint enforced in one place.
The consistency ladder
| Model | Guarantee | Cost | Example systems |
|---|---|---|---|
| Strict serializable | Transactions appear atomic in real-time order | Highest: consensus plus clock bounds | Spanner, FoundationDB, CockroachDB (with caveats) |
| Linearizable | Single-object reads see the latest completed write | A quorum or leader round trip per operation | etcd, ZooKeeper writes, DynamoDB strongly consistent reads |
| Sequential | One global order that respects each client's program order | High | ZooKeeper reads served locally without sync |
| Causal | Causally related operations are seen in order | Dependency metadata | MongoDB causal sessions, COPS research |
| Session guarantees | Read-your-writes, monotonic reads and writes | Sticky routing or tokens | Cosmos DB session level (the default) |
| Eventual | Replicas converge if writes stop | Lowest | DNS, Cassandra at consistency level ONE |
Checking claims
Jepsen analyses have repeatedly shown databases advertising a model and violating it under partitions or clock skew. When a design depends on a guarantee, test it with fault injection. Do not rely on the marketing page.