HTTP Caching
HTTP caching describes mechanisms and rules for storing HTTP responses to reduce latency, bandwidth usage, and backend load.
Classification
- ComplexityMedium
- Impact areaTechnical
- Decision typeArchitectural
- Organizational maturityIntermediate
Technical context
Principles & goals
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.
✔Benefits
- Reduced latency for end users
- Lower origin server load
- Cost savings through reduced backend resource usage
✖Limitations
- Difficulties with consistent invalidation
- Not all responses are deterministically cacheable
- Increased complexity for personalized content
Trade-offs
Metrics
- 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.
Examples & implementations
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.
Implementation steps
Audit existing endpoints and classify by cacheability.
Define cache policies, TTLs, and cache keys.
Configure CDN/proxy policies and purge mechanisms.
Implement conditional requests (ETag/Last-Modified).
Set up monitoring and iterate adjustments.
⚠️ Technical debt & bottlenecks
Technical debt
- Ad-hoc cache purges instead of implemented invalidation APIs.
- Inconsistent cache keys across services.
- Missing tests for cache behavior in deployment processes.
Known bottlenecks
Misuse examples
- 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.
Typical traps
- Confusing Cache-Control with server-side session logic.
- Overriding proxy caches due to incorrect header ordering.
- Insufficient observability of cache effects in production.
Required skills
Architectural drivers
Constraints
- • HTTP standards and header behavior
- • Third-party CDN APIs and limits
- • Legal requirements for personal data