A client polling `GET /leaderboard` every thirty seconds re-downloads the exact same payload almost every time, because the underlying data changes far less often than the poll interval — and every one of those redundant downloads costs the same bandwidth, the same server-side serialization work, and the same round-trip latency as a request that actually returned something new. Multiply that by every client polling every endpoint across a real API, and a large fraction of total traffic turns out to be the server re-telling clients things they were already told.
A second, unrelated-looking problem shows up the moment more than one client can write to the same resource: two admins open the same product record, both edit different fields, and both save. Whichever `PUT` reaches the server second silently overwrites everything the first one wrote, including the fields the second admin never even looked at — not because anyone did anything wrong, but because neither client's request carried any information about what state it assumed the resource was in when it started editing.
Both problems — wasted re-fetching and silent lost updates — are solved by the same underlying mechanism: a validator that represents the resource's current state, checked conditionally before the server does any real work. `ETag` and conditional requests turn "send me this again" into "send me this again only if it's actually different" for reads, and turn "save this" into "save this only if nothing changed since I last looked" for writes.
Analogy🏏Cricket
🏏 Think of it like cricket: A physical scorebook kept during a match has exactly one authoritative copy, and two scorers working from it never both write into it at once without checking what the other just entered — a scorer picking up the book after tea always glances at the last entry first, confirms it matches what they expect the score to be, and only then writes the next delivery's outcome. If a second scorer instead started filling in deliveries from their own separate notes without first checking the book's actual current state, and their notes happened to be a few deliveries behind because they'd stepped away, writing directly into the book would silently overwrite entries the first scorer had already correctly recorded — the book would end up wrong, and nothing about the act of writing would have flagged that anything was overwritten. A disciplined scorer instead always reads the book's current last entry before adding to it, and if it doesn't match what they expected, they stop and reconcile before writing anything, rather than trusting their own possibly-stale notes and overwriting blind. Just as a scorer checks the book's actual current entry before adding to it, an API client should check a resource's actual current state — via a validator like an ETag — before saving a change to it. Just as reconciling first prevents one scorer's stale notes from silently erasing another scorer's correct entry, checking a resource's current validator before a write prevents one client's stale view from silently overwriting another client's already-saved change. The insight is that preventing a lost update doesn't require locking the book so only one person can ever touch it — it requires making every write prove it started from the actual current state before it's allowed to happen.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.