Micro Caching and CDN

Micro caching stores dynamic, non-personalized responses for a very short window, usually 1 to 10 seconds, so your server builds a page once and then serves that copy to everyone who asks for it during that window. Pair it with a content delivery network and the cached copy lives at the edge, close to users, which is how busy sites keep Time to First Byte low even when traffic surges. This guide explains what micro caching is, how it differs from standard CDN caching, how the request flow works, how to configure it, and exactly when the two together are worth it. The numbers behind a one-second cache are bigger than most engineers expect.

Key Takeaways

• Micro caching stores dynamic, non-personalized content for 1 to 10 seconds, so a single generated response can serve thousands of visitors before it refreshes.
• On NGINX, a 1-second micro cache can take one server from roughly 5 requests per second to 600, and past 2,000 once you add cache locking and stale-while-revalidate.
• A CDN caches content on edge servers near users; micro-caching extends that idea to fast-changing pages that a standard CDN would otherwise send back to the origin.
• Combining the two lowers TTFB, offloads the origin during spikes, and keeps content no more than a second or two stale, with no per-change purging required.
• Micro caching only pays off on high-traffic endpoints where many users hit the same URL inside the cache window.
• Never micro-cache personalized content such as carts, checkouts, or logged-in dashboards.

What Is Micro Caching?

Micro caching is the practice of caching dynamic content for a very short time, typically 1 to 10 seconds, so the origin generates a response once and the cache serves it to every other request that arrives during that window.

This flips a common assumption. Most engineers treat database-driven or CMS-driven pages as uncacheable because they change. Micro caching says they are cacheable, just briefly. A news homepage, a product listing, a forum thread, or a public API endpoint may update often, but rarely more than once per second.

The payoff is two-fold: faster responses and far less origin work. During the cache window, the server skips application code, database queries, and template rendering for everyone except the single request that refreshes the entry. Because the window is so short, content is never more than a second or two old, so you get most of the speed of full-page caching without the headache of cache invalidation.

Think of it like a barista who brews a fresh pot every minute instead of grinding beans for each customer. The coffee is still fresh, but one brew serves the whole line. That is micro caching: one render, many visitors, refreshed constantly.

Micro caching fits best on:

• High-traffic dynamic pages that are the same for every visitor (news, marketing, landing pages, forums).
• Public API responses that many clients request at once.
• Pages where a one or two-second delay in updates is completely acceptable.

But a micro cache on a single server only protects one location. To serve users worldwide at the same speed, you need to understand what caching looks like inside a CDN.

What Is Caching in a CDN?

CDN caching stores copies of your content on edge servers spread across the globe, so requests are answered from a nearby Point of Presence (PoP) instead of your distant origin server.

A content delivery network (CDN) sits between your users and your origin. When a request arrives, the edge checks its cache. On a hit, it returns the stored copy in a few milliseconds. On a miss, it fetches the file from the origin, returns it, and keeps a copy for next time. For static assets, this routinely cuts round-trip times from hundreds of milliseconds to single digits, and 50% to 80% off page load times for global users.

Here is the catch. Traditional CDNs cache static assets aggressively- images, CSS, JavaScript, and fonts- but by default they leave HTML to the origin. So for a dynamic page, the browser still waits on your server to build the document before anything renders, and Time to First Byte stays high.

Real example: A user in California requesting a page from an origin in Virginia might spend about 85 ms each way on the network, plus 600 ms for the server to build the HTML. That is roughly 770 ms before the first byte. Caching the images and CSS does nothing for that 600 ms of server time.

What a standard CDN handles well versus poorly:

• Handled well: long-lived static files, large media, software downloads, anything with a versioned URL.
• Handled poorly by default: dynamic HTML, frequently changing pages, and API responses that the origin still renders on every request.

That gap, fast static assets but slow dynamic HTML, is exactly where micro caching and a CDN start working as a team.

Micro Caching vs CDN Caching: How They Differ

They solve different halves of the same problem. Standard CDN caching handles long-lived static assets; micro caching handles short-lived dynamic responses. Used together, they cover almost everything a page needs.

What most people miss: these two are not competitors. The strongest setups run a micro cache on top of the CDN’s edge, so static files are cached for weeks and dynamic pages are cached for a second, both close to the user.

So how does a one-second cache actually behave, request by request?

How Does Micro Caching Work?

A request arrives at a cache layer, a reverse proxy, or a CDN edge. If a fresh copy exists, it is served instantly as a hit. If not, exactly one request is sent to the origin, the response is stored with a short TTL, and every other request is served from that stored copy until it expires.

The cache lifecycle

Most caches expose their state through a status header. The states you care about are:

• HIT: a fresh copy was served from cache, often in under 10 ms.
• MISS: no copy existed, so the request went to the origin, and the result was stored.
• EXPIRED: the copy existed but its TTL elapsed, so it is being regenerated.
• UPDATING: the entry is being refreshed right now by another request.
• STALE: a slightly old copy is being served on purpose while the refresh happens in the background.

Stopping the thundering herd

On a busy endpoint, the moment a 1-second entry expires, hundreds of requests could rush the origin at the same instant. This is the thundering herd, also called a request stampede, and it can wipe out the benefit of caching. Three controls prevent it:

1. Cache lock: only one request is allowed to refresh an expired entry; the rest wait briefly.
2. Serve-stale-while-updating: other requests get the slightly old copy instead of hitting the origin.
3. Request collapsing (also called coalescing) at the CDN edge: multiple cache-fill requests for the same key collapse into a single origin request per edge node.

Knowing the mechanics is one thing. Here is the configuration that makes it real.

How to Set Up Micro Caching on NGINX

Define a cache zone, cache successful responses for one second, then add a cache lock and stale-while-revalidate so only one request refreshes each entry. A minimal production-style block looks like this:

What each piece does:

• proxy_cache_valid 200 1s: store successful responses for one second.
• proxy_cache_lock on: prevent the stampede when the entry expires.
• proxy_cache_use_stale updating and background_update on: keep serving while a single request refreshes.
• X-Cache-Status: expose HIT, MISS, EXPIRED, and UPDATING so you can confirm it works with curl or dev tools.

That single change is dramatic. On a dynamic page, a basic 1-second micro cache lifts one server from about 5 requests per second to 600, and tuned settings push it past 2,000.

The single-server gains are large. They get larger when the same logic runs across a global edge.

Benefits of Combining Micro Caching with a CDN

Running a short-TTL micro cache at CDN edge locations means dynamic pages are built once per location per second and served to nearby users in milliseconds. That lowers TTFB and shields the origin at the same time.

Stacking the two delivers benefits a CDN alone cannot:

• Lower TTFB on dynamic pages: edge full-page caching can cut TTFB by 200 to 800 ms depending on origin distance and processing time.
• Origin offload during spikes: most requests are absorbed at the edge, so your origin only handles refreshes and truly personalized traffic.
• Global consistency: with edge computing, the cache and even some logic run close to every user, not just one data center.
• Smart routing: DNS-based routing sends each visitor to the nearest PoP, shortening the path before caching even kicks in.
• No purge gymnastics: short TTLs expire on their own, so fast-changing pages stay fresh without invalidation pipelines.

Yes, but: you might say a CDN already speeds up your site. It does, for static assets. If it only caches images and scripts, your dynamic HTML still round-trips to the origin on every request. A micro cache at the edge is what closes that last gap and makes the dynamic part fast too.

This power comes with sharp edges. Use it on the wrong content, and you will serve the wrong data to the wrong person.

When Should You Use Micro Caching, and When to Avoid It?

Use micro caching on high-traffic, non-personalized, frequently-changing endpoints. Avoid it on anything personalized or low-traffic, where it adds risk without adding speed.

Good fits for micro caching:

• Busy homepages, category and listing pages, and article pages that are identical for every visitor.
• Public, read-heavy API endpoints hit by many clients at once.
• Forums, comment threads, and live blogs where a one-second delay is invisible to users.

Skip micro caching for:

• Carts, checkouts, account pages, and anything tied to a session or login.
• Low-traffic pages where the cache rarely gets a second request before it expires, so it never warms up.

Objection: you might think a one-second cache is too short to matter. On a page taking 10,000 requests a minute, a 1-second cache still absorbs about 99% of them. Short does not mean weak when traffic is high.

Even on the right content, a few configuration slips can quietly break things.

Common Micro Caching Mistakes to Avoid

Most micro caching failures are not about TTL length; they are about caching the wrong thing or skipping a safeguard. Watch for these:

• Caching personalized content: if a response varies by user and you cache it, one visitor can see another’s data. Bypass the cache whenever a session cookie or auth header is present.
• A TTL longer than your update rate: if content changes every second but you cache for 30, users see stale pages. Match the TTL to how fast the page really changes.
• A weak cache key: caching by path alone when query strings or headers change the output serves the wrong variant. Include what matters in the key.
• No cache lock: every expiry becomes a stampede, and your origin load spikes instead of dropping.
• No monitoring: if you never check cache hit ratio or X-Cache-Status, you cannot tell whether caching is helping at all.
• Leaving security to the cache: cached traffic is not filtered traffic. Pair caching with a web application firewall so the dynamic requests that do reach your origin are screened first.

Avoid those, and a short checklist keeps you in the fast lane.

Micro Caching Best Practices for Low-Latency Delivery in

The teams that get the most out of micro caching treat it as a measured, layered strategy, not a single switch. A practical playbook:

1. Start at a 1-second TTL on your hottest dynamic endpoints, measure the effect, then tune up or down based on real change frequency.
2. Always pair a short TTL with a cache lock, stale-while-revalidate, and background updates so refreshes never stampede the origin.
3. Separate personalized from cacheable content by path, so a single misconfiguration cannot leak a logged-in page.
4. Run the micro cache at the edge, not just at the origin, so users in every region get the fast path.
5. Track cache hit ratio, origin offload percentage, and TTFB by region; let those numbers, not guesses, set your TTLs.
6. Keep caching static assets aggressively with long TTLs and versioned URLs, so the micro cache only carries the dynamic load.

Final Thought on Micro Caching

Speed at scale is rarely about a faster server. It is about asking the server to do less. Micro caching is the cheapest way to make a dynamic site behave like a static one without giving up freshness, and a CDN extends that benefit to every region you serve. One render, served to thousands, refreshed every second, close to the user.

The win comes from balancing aggressive caching with honest boundaries. Cache what is shared, never what is personal, keep TTLs short, and let the edge do the heavy lifting. Measure TTFB and cache hit ratio, and let the data, not instinct, set your numbers. Get that balance right, and the same hardware quietly handles many times the traffic, with lower latency for everyone.

Frequently Asked Questions About Micro Caching