Consistency: what a client can see

What is the difference between eventual and strong consistency?

Eventual consistency promises only that copies agree once writes stop arriving; until then a read may return an older value from a lagging copy. Strong consistency (linearizability) promises that every read sees the latest completed write, as if there were one copy. The price of the strong version is that every operation has to reach a leader or a majority, which adds a round trip and stops working when that majority is cut off. Most designs use eventual consistency for most reads and pay for more only where a wrong answer costs money or trust.

How do you give read-your-writes on top of read replicas?

Have every write return a version (a log position or a per-key counter) and keep it with the client as a session token, in a cookie or a header. A read then goes to any replica whose version is at least the token, and to the leader, or waits, when none has caught up. Only the author carries a high token, so strangers keep reading from any replica. The leader sees the writes plus the author reads that land inside the replication lag, which is a few percent of the traffic.

What are monotonic reads and why do they need the token too?

Monotonic reads mean a client never sees a value and then an older one, which happens when two reads land on replicas at different lag. The fix is the same session token, raised on every read as well as every write: whatever version you saw becomes the floor for your next read. If the token only moves on writes, a reader who never writes gets no protection at all, which is the classic bug.

Is last-writer-wins safe for a shopping cart?

Not for the whole cart. If two devices edit the cart on two replicas at about the same time, last-writer-wins keeps one cart and silently drops the other edit. Keep the stamp per item instead, so edits to different items never collide, and break exact clock ties by replica id so every copy picks the same winner. Removals are stored as a quantity of zero with their own stamp, so an older add cannot bring an item back.

When do you actually need linearizability?

When an invariant spans all copies and breaking it cannot be undone cheaply: never selling more seats than exist, never letting two clients hold the same lock, never letting a balance go negative. Those operations go through one leader (or a consensus group) that checks and updates in one step. A like counter, a view count or a feed does not need it; a per-replica counter merged later is cheaper and never refuses a write.