Tensions in Practice: Fast repeated reads in tension with freshness¶
Derived results · reads and updates
A dashboard can recompute its answer from the source on every read, or reuse a stored result. Reuse saves work, but an update to the source can leave the copy behind. A scheduled refresh accepts that gap; a coordinated invalidation rule makes readers check whether reuse is still permitted. The choice depends on what an out-of-date answer would mean, not just on how quickly the screen responds.
Avoid repeated work
Answer repeated reads without rebuilding the same result each time.
Respect the freshness requirement
Do not present a copy as current when the application requires newer source state.
Why these aims pull against each other
Keeping a derived copy current requires update or invalidation work. Reducing that coordination makes reuse cheaper but permits a gap between the source and the answer.
Choose an arrangement to see what changes and what remains difficult.
Qualitative paths and conditions, not measured costs, timings or performance guarantees.
What this choice protects
What it costs
When it fits
Compare the arrangements
Read the source
Each request reads authoritative data and recomputes the result.
- What it protects
- No separate reusable copy can silently fall behind its source.
- What it costs
- Repeated requests repeat access and computation; the source receives the full read workload.
- When it fits
- A useful baseline when reuse is low, freshness is strict, or maintaining a copy costs more than it saves. Source-read consistency still depends on the underlying system.
Illustration note: The no-cache path is an editorial baseline derived from Caching’s definition; it is not a claim that every source read is instantaneous or transactionally consistent.
Refresh on schedule
Reads use a stored result while a separate schedule rebuilds it from authoritative data.
- What it protects
- Repeated reads avoid the expensive computation and do not each coordinate a refresh.
- What it costs
- Source changes can be missing from answers until refresh; a failed or delayed refresh can lengthen that gap.
- When it fits
- The application must permit the stated staleness and detect refresh failures rather than treating the schedule as proof of freshness.
Illustration note: The diagram selects scheduled refresh from the related mechanism. It supplies no numeric age limit or promise that a scheduled job succeeds.
Coordinate with updates
Changes invalidate affected derived results. A read reuses a valid copy or rebuilds an invalid one before returning it.
- What it protects
- Reuse remains possible while the update path controls which copies may still be served.
- What it costs
- Invalidation and rebuilding add coordination, and reads can wait. Missed invalidations can still produce stale answers.
- When it fits
- Every relevant update must participate, and invalidation must be ordered correctly with reads for the intended consistency contract.
Illustration note: The gate is an editorial rendering of on-write invalidation. It illustrates the required contract; it is not a complete concurrency protocol or a proof of strong consistency.
What this illustration does—and does not—establish
Caching: Coherence / Staleness Tradeoff supplies the coherence cost. The related materialized-view mechanism supplies scheduled refresh and on-write invalidation. Paths and the source-read baseline are editorial illustrations.
- Freshness is application-specific; no universal refresh interval or cache policy follows.
- The coordinated sketch assumes a correctly implemented update/read contract. Simply sending an invalidation message does not establish it.
- The source remains authoritative in all three arrangements; no cache is a substitute for defining what a valid read means.
Source entries
Caching
Caching: Coherence / Staleness Tradeoff supplies the conflict examined here.
Coherence / Staleness Tradeoff
- T1: Coherence / Staleness Tradeoff. Strong coherence (cache always reflects source) requires invalidation or write-through, imposing overhead. Weak coherence (eventual consistency, TTL-based freshness) is faster but risks serving stale data. The right choice depends on the semantic requirements and the cost of staleness. Mismatched coherence model — strong where weak would suffice (slow), or weak where strong is needed (incorrect results, security bugs, financial errors) — is a failure mode.
Core Idea
Caching is the technique of maintaining a fast, local, usually-smaller copy of information whose original is slow to produce or fetch, so that repeated or nearby accesses are served from the copy rather than from the source — exploiting *locality of reference* (the empirical observation that accesses exhibit temporal and spatial clustering) to reduce average latency, bandwidth consumption, computational cost, or coordination overhead. The essential commitment is that a multi-tier storage or computation architecture with a small-fast tier and a large-slow tier can dramatically outperform either alone, given workloads with sufficient reuse, and that the cache's effectiveness depends jointly on the workload's locality, the cache's size and organization, the replacement policy, and the coherence (correctness) guarantees.
Materialized View or Cache
Supplies concrete scheduled and on-write refresh choices for derived results, including staleness monitoring.
How it works
- Precompute the costly result (aggregate, join, projection) and store it as a derived structure keyed for direct read. - Serve reads from the stored result; the authoritative base is untouched and remains the source of truth. - Refresh by schedule, on-write invalidation, or on demand — and monitor staleness (age since refresh) and hit rate.
When it helps, and when it misleads
The derived copy can drift from its base, and a stale result served as truth is the failure that gives cache invalidation its reputation as one of computing's genuinely hard problems. The classic misuse is caching data that changes as fast as it is read — near-zero hit value, constant invalidation — or leaning on the cache until people forget where truth actually lives. The discipline is to keep the base authoritative and the view disposable, set an explicit staleness budget, and monitor drift so a stale view fails loud rather than silent.