Writes Follow Reads is one of the four session consistency guarantees, and it's the one most engineers have never heard of — until it bites them. The rule: if a session reads a value, any subsequent write from that session must be applied to a replica that has at least seen that value. In other words, you can't write on top of a version older than what you just read.

Why does this matter? Because users (and your code) make decisions based on what they read, and those decisions become writes. If the write lands on a replica that's behind the read, you've effectively traveled back in time.

Concrete example — a moderation queue. A moderator opens a flagged comment, reads its current state (status: pending, flags: 3), and clicks "approve." The approval write goes to replica B, which is 30 seconds behind replica A (where the read happened). Replica B still shows status: pending, flags: 1 — it never saw the third flag arrive. The approve write succeeds against the stale state, and now you've approved a comment based on information the writing replica didn't even know existed. When replication catches up, conflict resolution may silently overwrite the third flag, or worse, the approval gets applied to a comment whose flags weren't fully counted.

How systems enforce it:

• Version vectors per session: the client tracks the max version it has read. Writes include this version, and the receiving replica refuses (or waits) until it has caught up.
• Sticky routing to a "fresh enough" replica: route writes to a replica whose replication lag is below the highest read timestamp from the session.
• Read-then-write to the leader: the simplest fallback — if a read will feed a write, just do both against the primary.

Rule of thumb: if a read-modify-write cycle spans more than one network round-trip, Writes Follow Reads is the guarantee you need. For pure blind writes (e.g., "append this log line"), you don't — the write doesn't depend on prior state.

Cost calculation: enforcing it via version tracking adds roughly 16–32 bytes per request (a vector clock or LSN) and may add one extra hop when the chosen replica is behind. On a system doing 10k writes/sec, that's ~300 KB/s of metadata — trivial. The cost of not enforcing it is silent data corruption that you'll discover three months later in a customer support ticket.

Don't confuse this with Read-Your-Writes (see your own writes) or Monotonic Reads (never go backwards in time on reads). Writes Follow Reads is specifically about the causal chain from a read to a subsequent write.