Banyan Village had only one Great Wall of Notices — the whitewashed wall behind the ancestral hall. Every announcement in the village was written there: whose goat had wandered off, which day the market had moved to, where a boundary now ran. But the village sprawled, and from the far hamlet of Xitang it was a ninety-minute walk to the hall. The old people could not manage it.

So seven copy-walls were built. Each time the clerk finished a notice, he handed it to a young runner, and the runners fanned out to seven lane-mouths and copied it onto the wall there. Some runners were quick, some slow; in the rain, slower still. So the copy-walls always trailed the Great Wall by a little. By how much, nobody could say.

Most of the time nobody cared. Then Old Qin lost his goat.

He walked to the hall at dawn, had the clerk write a notice, watched it go up on the Great Wall with his own eyes, and walked all the way home to Xitang. At the lane-mouth he looked up at the copy-wall — empty. He waited. Still empty.

Old Qin exploded. “I wrote it myself and I can’t even see it myself?”

The clerk came, and did not argue. He drew a bamboo tally from his sleeve and cut a number into it: four thousand and twenty-one. “That is your notice’s number on the Great Wall. From now on, before you read any copy-wall, hand this to its keeper.”

Every keeper had a tally of his own, cut with the number his wall had copied up to. Old Qin handed his over; the keeper saw his own wall stood at four thousand and nine — not there yet — and said, “Sit a moment, the runner is close.” And when Qin could not wait, the keeper pointed: “The east-lane wall is already at four thousand one hundred. Read it there.”

From that day Old Qin never again failed to find his own notice.

The second trouble was Aunt Wang’s. In the morning, at the east-lane wall, she read that the market had moved to the eighth. That afternoon she passed the south-lane wall, which still said the sixth. She believed the second wall, and missed the market.

The clerk issued her a tally too — but this one was cut not with what I wrote but with what I have already seen. Each time she read a wall, its keeper notched her tally upward. After that, whenever her number stood higher than a wall’s, the keeper would not let her read it. “You already know more than this wall does. Reading it would only confuse you.”

The third trouble was the subtlest. Someone read “the Li family’s ox has strayed” on a copy-wall and pinned up a reply: “the ox is in my field.” The two slips went to different runners by different paths, and on the south-lane wall the reply appeared first, with nothing beneath it — nobody knew which ox. So the clerk made a rule: a reply must travel together with the notice it answers, and may not go up until that notice is up.

And two notices from the same hand — “my field is for sale” and “the field is no longer for sale” — the clerk never let the runners reorder, however tempting the shortcut.

The village was the same village. The Great Wall still led, the copy-walls still trailed, the runners were still fast or slow. Nothing had been made faster. Everyone simply carried a small bamboo tally now.

— By now you have probably recognized it: this is not a story about notice walls. The Great Wall is the primary, the copy-walls are read replicas, the runners are asynchronous replication, and the number on the tally is a version token (etcd calls it resourceVersion; a database calls it an LSN). This is the story of session guarantees, whose most famous clause is read-your-writes consistency.

What it is

Eventual consistency promises exactly one thing: if writes stop, replicas will converge. It says nothing about the journey — and in particular nothing about what a single client sees along the way. Almost every “I definitely saved it, but the page shows the old value” mystery lives on that journey.

The answer Terry et al. gave in the Bayou system in 1994 was not to strengthen the store, but to attach four rules to each session:

• Read your writes: what you wrote, you will subsequently read.
• Monotonic reads: what you have seen will not vanish on your next read — time may not run backwards.
• Writes follow reads: a write you made on the basis of a read cannot land before that read (causal order).
• Monotonic writes: your own writes take effect in the order you issued them.

The mechanism is the tally: the client carries a version token and presents it with each request. The replica compares it against its own applied version, and has only three moves — wait for replication to catch up, redirect to a fresh-enough replica (or straight to the primary), or refuse to serve a view older than what the client already knows.

The crucial property is that these guarantees are per-client, requiring no extra coordination between replicas. That makes them far cheaper than linearizability: instead of making the whole system look like one machine, you only make each person’s own timeline coherent.

Why it matters

This is the standard trap in read/write splitting: write to the primary, read from a replica, and the user who refreshes right after submitting sees the world as it was before they acted. Aurora/RDS replica lag, cross-region replication, CDN and DNS caches — all the same disease.

Closer to home, in Kubernetes: kubectl get right after kubectl apply occasionally misses the change, because the request landed on another kube-apiserver’s watch cache (resourceVersion=0 means “arbitrarily stale is fine”). The fix is to carry the resourceVersion from the write response into the next List with ResourceVersionMatch: NotOlderThan — handing the tally to the keeper. Controllers face it too: acting on your own informer cache immediately after writing an object is the classic stale read, which is why expectations and resyncs exist at all.

And finally, its failure mode: lose the tally and the guarantee is gone. The user switches devices, the load balancer lands the session on a different pool, or the token isn’t propagated across a hop (browser → BFF → backend) — and the timeline breaks. When that happens, the only honest fallback is to read from the primary.

Metaphor mapping

• The Great Wall — the primary/leader, the single point of write
• The seven copy-walls — read replicas, asynchronous, each lagging differently
• The young runners — asynchronous replication with unbounded, uneven delay
• The tally cut with 4021 — the version token returned by the write (resourceVersion / LSN)
• The keeper’s own tally — the version the replica has currently applied
• “Sit a moment, the runner is close” — read-after-write wait for replication to catch up
• “Read it at the east-lane wall” — routing to a fresh-enough replica, or falling back to the primary
• Aunt Wang’s “what I have seen” tally — monotonic reads, a lower bound on the session’s read version
• “A reply travels with the notice it answers” — writes follow reads, causal dependency
• The two field notices that may not be reordered — monotonic writes
• Losing the tally — losing the session token; the guarantee degrades to plain eventual consistency