Caching stores copies of data in a faster storage layer so repeated requests are served without fetching from the original source — reducing latency, backend load, and infrastructure costs.
TL;DR Caching is the practice of storing a copy of data in a fast, temporary storage layer (the cache) so future requests can be answered without repeating the original computation or database query. A cache hit returns data instantly from the cache. A cache miss fetches from the origin and stores the result for future use. Caching reduces response times from hundreds of milliseconds to under 10 milliseconds for repeated requests. Every layer of the modern web uses caching: CPUs, browsers, application servers, databases, CDNs, and distributed networks.
What is caching?
Caching is storing a reusable copy of data in a faster storage layer so subsequent requests for the same data can be served without repeating the original fetch or computation.
The fundamental mechanics:
- Cache hit — The requested data is found in the cache. Returned immediately, no origin request needed.
- Cache miss — The requested data is not in the cache. The system fetches from the origin, stores the result in cache, then returns it.
- TTL (Time To Live) — The duration for which a cached item is considered valid before it must be refreshed.
- Eviction — When the cache is full, old or less-used items are removed to make space. Common policies: LRU (Least Recently Used), LFU (Least Frequently Used), FIFO (First In First Out).
Types of caching
Caching happens at every layer of the technology stack:
| Cache layer | Where it operates | What it caches | Typical latency |
|---|---|---|---|
| CPU cache (L1/L2/L3) | Inside the processor | Instructions and data from RAM | < 1 nanosecond |
| Browser cache | User’s device | HTML, CSS, JavaScript, images | 0ms (local disk) |
| Application cache | App server memory | Computed results, session data | < 1ms |
| Database query cache | Database layer | Query result sets | < 5ms |
| CDN / edge cache | Distributed network nodes | Static and dynamic web content | < 10ms (nearest PoP) |
| DNS cache | Resolver and OS | Domain-to-IP mappings | < 1ms (after first lookup) |
Caching strategies
| Strategy | How it works | Best for | Risk |
|---|---|---|---|
| Cache-aside (lazy loading) | App checks cache first; on miss, loads from origin and populates cache | Read-heavy workloads | Initial cold start |
| Write-through | Every write goes to cache and origin simultaneously | Consistency-critical data | Slower writes |
| Write-back (write-behind) | Writes go to cache first; origin is updated asynchronously | Write-heavy, high-throughput | Data loss on cache failure |
| Read-through | Cache handles the fetch transparently; app only talks to cache | Simplifying app logic | Cache library dependency |
| Stale-while-revalidate | Serve stale cached content immediately; refresh in background | Web performance, CDN | Brief staleness acceptable |
HTTP caching headers
CDN and browser caching is controlled by HTTP headers:
| Header | Meaning |
|---|---|
Cache-Control: max-age=3600 | Cache this response for 3600 seconds (1 hour) |
Cache-Control: no-store | Never cache this response anywhere |
Cache-Control: no-cache | Cache it, but revalidate with the origin before serving |
Cache-Control: public | Response can be cached by shared caches (CDNs, proxies) |
Cache-Control: private | Only the end user’s browser may cache this |
ETag | A unique identifier for a version of a resource; enables conditional requests |
Vary | Tells caches to store separate versions based on specified headers (e.g., Vary: Accept-Encoding) |
Cache invalidation
Cache invalidation is the process of removing or updating cached data before its TTL expires. It is one of the hardest problems in distributed systems.
Methods:
- Purge — Explicitly delete a specific cached URL or key.
- Tag-based invalidation — Group cache entries by tag and purge all entries sharing a tag at once.
- Versioned URLs — Embed a version hash in asset URLs (e.g.,
style.abc123.css); new version = new URL = automatic cache miss. - Surrogate keys — Used by CDNs to invalidate groups of related objects with a single API call.
Common caching mistakes
| Mistake | Consequence | Fix |
|---|---|---|
Caching personalized responses without Vary | User A receives User B’s private data | Add Vary: Cookie or avoid caching private responses |
| TTL set arbitrarily high | Stale content shown to users after updates | Set TTL based on how often data actually changes |
| No invalidation plan | Cached errors and outdated content persist indefinitely | Implement purge endpoints or versioned URLs |
| Caching 500/error responses | Error responses served from cache for hours | Explicitly exclude non-2xx status codes from caching |
| Cache stampede on expiry | Spike of origin requests when popular cached item expires simultaneously | Use stale-while-revalidate or request coalescing |
Frequently asked questions
What is caching in simple terms? Caching stores a copy of data in a faster location so the same data can be returned quickly next time without fetching it again from the original source.
What is a cache hit vs a cache miss? A cache hit means the requested data was found in the cache and returned immediately. A cache miss means the data wasn’t in the cache — the system had to fetch it from the original source, which takes longer.
What is TTL in caching? TTL (Time To Live) is the number of seconds a cached item is considered valid. A TTL of 3600 means the item is cached for 1 hour. After TTL expires, the next request triggers a fresh fetch from the origin.
Is a CDN the same as caching? No. A CDN (Content Delivery Network) is a distributed network of servers. Caching is one of the techniques CDNs use. Caching also happens in browsers, applications, databases, and other layers entirely separate from CDNs.
What is cache invalidation and why is it hard? Cache invalidation means removing or updating cached data before its TTL expires. It’s hard because in distributed systems, the same data is cached in multiple places simultaneously — a cache entry may need to be invalidated across hundreds of edge nodes, multiple browser caches, and application-level caches all at once.
How does browser caching work? Browsers cache assets (images, CSS, JavaScript) based on HTTP response headers. The Cache-Control: max-age header tells the browser how long to keep the file. When the TTL expires, the browser requests a fresh version from the server.
What is stale-while-revalidate? Stale-while-revalidate is a caching directive where the cache serves a slightly outdated (stale) response immediately while simultaneously fetching a fresh version in the background. This eliminates the latency of revalidation without serving significantly outdated content.
What is the difference between cache-aside and read-through caching? In cache-aside, the application code manages the cache — it checks the cache, and on a miss, loads data from the origin and populates the cache itself. In read-through, the cache layer handles fetching from the origin transparently, and the application only interacts with the cache.