Strong versus eventual consistency

01What may a read observe?

A user saves a new profile photo and receives success. Someone then reads that photo. What may the API return?

1. Linearizable read/write behavior: the later-starting read cannot return the earlier photo unless another write changed it again. Operations behave as though they occurred at single instants in one order respecting completed-before-started timing. This is this chapter's strong consistency for one object.
2. Eventual consistency: a replica may return an older photo while updates are still spreading. If new writes stop and delivery/repair assumptions hold, copies eventually agree.

Eventual does not mean “within five seconds,” “your session immediately sees its own edit,” or “all writes have one global order.” Specify those extra promises and their mechanisms separately.

A transaction changing several objects asks another question: whether concurrent transactions behave like a valid one-at-a-time order. That is serializability; ordering one photo alone does not automatically protect a multi-record purchase.

02Coordination and failure determine the cost

Use increasing photo versions to make the read promise observable. Version 8 finishes saving at time 10; a read begins at time 11 with no later write.

For a session that must see its own edit:

1. Return version 8 with the save result.
2. Carry required version 8 on the next session read.
3. Choose a source known to have applied at least 8, or wait/fail under the documented policy.

A healthy nearby replica is not evidence that it has applied 8. Receiving update bytes is not the same as exposing the change to queries.

Another session guarantee, monotonic reads, prevents the session moving backward between versions it has already seen; it still need not see every latest global write. During a network partition, isolated sides cannot both guarantee successful service for the same data and linearizable operations. State which requests wait, reject or explicitly accept weaker reads.

03Worked example: profile and ticket inventory

Follow profile version 7 → 8:

1. The current profile-writing service commits 8 and returns success. One asynchronous replica still has 7.
2. A browsing read chooses that replica. Returning 7 is valid only if the endpoint permits an old observation. It is not a successful linearizable read starting after version 8 completed.
3. The editor asks to see their own change. Their request requires version 8. The service selects a sufficiently updated source, waits for one or returns the documented failure.
4. Another user may still see 7. Read-your-writes for the editor does not force every other session onto the same source.
5. The product adds a five-second maximum age. One API worker can start a timer when it requests a linearizable database read. That returned value was current at some point after the timer began, so the worker reuses it only until five seconds from that start. A four-second validation leaves at most one second of reuse. If the timer expires, validate again or reject. This example uses one clock; sharing timestamps across machines also needs a bound on their clock difference. A response from an old replica does not perform this validation.

Now replace the photo with one remaining seat. Two disconnected sellers each hold an old “available” value. If both independently confirm, later agreement cannot make the original no-double-sale promise true.

• Use one coordinated inventory operation that grants the seat only if it is still free, or allocate exclusive seats to sellers in advance.
• If a seller cannot establish its right to this seat, some confirmations must wait or fail.
• Do not use a later timestamp winner to justify two earlier promises. Last-write-wins can make copies agree while discarding one meaningful change; convergence is not preservation of business intent.

04Choose guarantees per action

Choose what each action may observe:

• Profile browsing: a little old data may be acceptable, while the editor's session sees its own write.
• Search stock hints: an approximate count may help discovery; purchase confirmation still requires a valid stock allocation.
• Strict freshness: identify where success is acknowledged, which source reads use and how required progress is proven.
• Network failures: say which operations wait or reject instead of silently weakening their promises.
• Repair: explain how delayed or conflicting copies catch up under the chosen data rules.

Stronger guarantees can add communication or reduce availability, but no universal delay penalty applies to every topology and protocol. In an interview, draw a completed write followed by a read, an overlapping write and a disconnected replica. Show which specific old response is permitted or rejected.