# Review a caching design for freshness and isolation

Canonical: https://githtml.com/guides/review-caching-design-for-correctness
Published: 2026-09-26
Publisher: WaveTech LLC / gitHtml

A caching review should start with correctness: what is stored, who may receive it, how long it remains valid, and what changes make it obsolete. Examine cache keys and ownership before performance claims. Distinguish HTTP caching from application caches, because they may follow different rules and expose different failure modes.

## Name the cache and the stored meaning

An illustrative document list might be cached in a browser, a shared HTTP layer, or an application memory store. Those are not interchangeable locations. MDN's caching guidance explains private and shared HTTP caches; use the correct model for the actual system. State whether the cached value represents public content, user-specific data, or a derived computation. Record what the key includes and what it intentionally excludes. A fast lookup is not a useful improvement if it can return another user's result or a value from the wrong configuration.

## Test a change in context

Walk through an illustrative sequence: a user opens a list, changes permissions, and opens it again. Ask which cache can answer the second request and how the permission change is reflected. Then consider an updated underlying record and an unavailable origin. Document freshness and invalidation behavior with source or configuration evidence rather than vague claims such as periodically refreshed. For HTTP responses, inspect the actual directives and relevant intermediaries. For application caches, find the code or service policy implementing the intended rule.

1. Key: identify all dimensions required to keep values correctly separated.
2. Freshness: explain when a cached value may be reused or must be checked.
3. Failure: describe behavior when the origin is unavailable or invalidation is delayed.

## Keep the conclusion scoped to the implementation

Do not infer that one observed cache hit establishes the whole lifecycle. Ask for tests or controlled evidence covering the boundary that matters to the proposal. Separate a privacy or correctness concern from an unmeasured performance benefit, and avoid approving one in exchange for an unsupported promise about the other. A static HTML review can make the reasoning portable, but it does not inspect live headers automatically. This discussion of application caching also should not be read as a promise that gitHtml automatically caches every remote stylesheet, image, or linked website.

## Sources and further reading

- [MDN: HTTP caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching)
- [OWASP: Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)

## Related guides

- [Trace data flow through a technical review document](https://githtml.com/guides/trace-data-flow-in-technical-review)
- [Review a PostgreSQL query-plan report safely](https://githtml.com/guides/review-postgresql-query-plan-report)
- [Review performance claims without being fooled by one fast run](https://githtml.com/guides/review-performance-claims-with-distributions)
- [Review test coverage by reading assertions, not percentages](https://githtml.com/guides/review-test-coverage-by-assertions)

Editorial approach: https://githtml.com/guides/about