Catalog
concept#Architecture#Software Engineering#Observability

HTTP Caching

HTTP caching describes mechanisms and rules for storing HTTP responses to reduce latency, bandwidth usage, and backend load.

HTTP caching controls how responses are stored, reused, and expired to reduce latency and bandwidth usage.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Intermediate

Technical context

CDNs (e.g., Cloudflare, Fastly, AWS CloudFront)Reverse proxies (e.g., Varnish, Nginx)API gateways and edge services

Principles & goals

Be explicit about cache validity: define TTL and validation.Separate public and private content: use distinct cache scopes.Favor simple invalidation strategies that can be automated.
Build
Enterprise, Domain, Team

Use cases & scenarios

Compromises

  • Serving stale content if invalidation fails
  • Misconfigured cache headers causing inconsistencies
  • Security risks when caching sensitive data
  • Version static assets instead of relying on aggressive purges.
  • Use Cache-Control granularly and document exceptions.
  • Measure and use hit rates to optimize TTLs.

I/O & resources

  • Analysis of response types and their cacheability
  • Existing CDN or proxy infrastructure
  • Security and privacy requirements
  • Defined cache policies and TTLs
  • Monitoring dashboards (hit rate, misses)
  • Automated invalidation workflows

Description

HTTP caching controls how responses are stored, reused, and expired to reduce latency and bandwidth usage. It includes Cache-Control directives, ETags, Last-Modified, Vary headers, and covers proxy and CDN behavior, cache hierarchies, TTL strategies, and cache key design. Architectural decisions balance consistency, freshness, invalidation complexity, scalability, monitoring, and performance trade-offs.

  • Reduced latency for end users
  • Lower origin server load
  • Cost savings through reduced backend resource usage

  • Difficulties with consistent invalidation
  • Not all responses are deterministically cacheable
  • Increased complexity for personalized content

  • Cache hit rate

    Share of requests served from cache.

  • Average response time (p95)

    95th percentile of response times; indicates performance impact.

  • Origin request rate

    Number of requests per second to the origin server.

CDN cache for static web assets

Assets are versioned and delivered with long TTLs via a CDN, while invalidation is done through filename versioning.

Reverse proxy caching for API responses

An edge proxy caches GET responses for frequent queries, reducing backend load and increasing throughput.

Conditional requests with ETag

Clients use ETags and If-None-Match to save bandwidth and transfer full content only on changes.

1

Audit existing endpoints and classify by cacheability.

2

Define cache policies, TTLs, and cache keys.

3

Configure CDN/proxy policies and purge mechanisms.

4

Implement conditional requests (ETag/Last-Modified).

5

Set up monitoring and iterate adjustments.

⚠️ Technical debt & bottlenecks

  • Ad-hoc cache purges instead of implemented invalidation APIs.
  • Inconsistent cache keys across services.
  • Missing tests for cache behavior in deployment processes.
Invalidation complexityCache key designMonitoring and observability
  • Caching user profile pages as public, causing privacy breaches.
  • Applying a long global TTL for dynamic API responses.
  • No purge API and using manual file changes for invalidation.
  • Confusing Cache-Control with server-side session logic.
  • Overriding proxy caches due to incorrect header ordering.
  • Insufficient observability of cache effects in production.
HTTP protocol knowledge and header mechanismsFamiliarity with CDN and proxy configurationMonitoring and metrics analysis
Latency reduction for end usersCost-efficient scaling of backendsData security and correct permissions
  • HTTP standards and header behavior
  • Third-party CDN APIs and limits
  • Legal requirements for personal data