One designated cell for many entries
The same rule that guides this whole subject also applies here: atomicity over n items is implemented as atomicity over one designated item. A table format does this with one snapshot pointer. For freshness it becomes a testable claim. Freshness over n cached entries needs one designated "version cell" if the entries must agree with each other. A per-entry TTL uses no such cell. Look at six designs:
| Design | Designated version cell? | Cross-entry consistency? |
|---|---|---|
| Lakehouse snapshot pointer | yes | yes |
| Buffer pool with a global LSN | yes | yes |
| A read timestamp handed to all caches (Percolator or Spanner style) | yes | yes |
| HTTP with per-resource ETags | no | no |
| CDN purge by URL | no | no |
| Memcached with per-key TTL | no | no |
The correlation is perfect across all six. That supports this claim:
It is necessary, not sufficient. You also need every entry keyed to, or checked against, that cell, and the entry set must be complete at that version.
Why state it? Because it is predictive. If your design has no designated cell, then no amount of TTL tuning will ever produce a consistent multi-object read. Every bug report like "the header said 47 but the list showed 46 rows" is unfixable inside that design. It is not a tuning problem. This is a useful thing to say in a design review, with an argument behind it.
(This is a proposed refinement, not a textbook theorem. It can be tested by looking for a system that offers bounded cross-object staleness with no designated cell. One such system would disprove the "necessary" half.)
Compression: One designated cell is necessary for cross-entry consistency and irrelevant to per-entry freshness. So "no cell" means multi-object consistency is unavailable, not badly tuned.