Stale copies / A visual field noteTechnical talk / 01

How can two reads disagree?

The source changed.
Your copy didn’t.

One source. One saved copy. A small model for a surprisingly common confusion.

SourceB
Saved copyA
Simplified teaching model · Illustrative example01 / 06
Stale copies / A visual field noteTechnical talk / 02

First, the source and copy agree.

Copy version A from the source. Both now hold the same value.

SourceA
Saved copyA
Simplified teaching model · Illustrative example02 / 06
Stale copies / A visual field noteTechnical talk / 03

The source moves on. The copy stays put.

The divergence happens here.

Changing the source does not update this saved copy. It still holds the last version it received.

Simplified teaching model · Illustrative example03 / 06
Stale copies / A visual field noteTechnical talk / 04

A refresh changes the copy. Not the source.

Before refreshBsource / unchangedAcopy
After refreshBsource / unchangedBcopy / updated

saved copy ← current source value

One successful operation

Read the source.
Replace the saved value.
Both now hold B.

State notation, not executable code. This model assumes the refresh succeeds.

Simplified teaching model · Illustrative example04 / 06
Stale copies / A visual field noteTechnical talk / 05

Stale doesn’t mean broken. It means behind.

ALast copied value

What the saved copy remembers.

BCurrent value

What the source holds now.

Two different versions. One missing refresh.

In this model, A and B are version labels—not clock times or a measure of how old the copy is.

Simplified teaching model · Illustrative example05 / 06
Stale copies / A visual field noteTechnical talk / 06

Ask one question: what refreshes this copy?

The whole storySourceCopy
Copy the sourceAA
Change the sourceBA
Refresh successfullyBB

Keep the model small.

This explanation omits expiry, automatic refresh, failures, concurrency, and multiple cache layers.

A mental model, not a universal caching policy.