---
title: "Cache and microcaching"
description: "Caching stores ready-made responses to avoid regenerating them; microcaching buffers dynamic pages for 1–10 seconds. See how both protect your server."
url: "https://nodea.io/en/glossary/cache-and-microcaching"
lang: "en"
updated: "2026-07-13"
---

# Cache and microcaching

> Caching stores the results of expensive operations so repeat requests are served instantly; microcaching is the variant that buffers fully dynamic pages for just a few seconds, shielding the backend under heavy traffic.

A **cache** is a storage layer that keeps the results of expensive work — rendered pages, database query results, API responses — so subsequent requests can be answered instantly instead of recomputing the same output. **Microcaching** is a specialised form of it: caching fully dynamic responses for a very short time, typically between one and ten seconds.

## How caching and microcaching work

Caching happens at several layers of the stack, each one offloading the layers behind it:

- **Browser cache** — static assets kept locally according to the [Cache-Control](https://nodea.io/en/glossary/cache-control) header;
- **Edge and proxy cache** — a [CDN](https://nodea.io/en/glossary/cdn), [Varnish](https://nodea.io/en/glossary/varnish-cache) or Nginx reverse proxy storing whole HTTP responses;
- **Application cache** — objects and query results held in Redis or Memcached;
- **Opcode cache** — compiled PHP bytecode reused by OPcache.

Microcaching lives at the reverse-proxy layer. The first request in a time window hits the backend and the generated page is stored; every following request within, say, five seconds is served straight from memory. Two supporting mechanisms matter in production: cache locking (only one request regenerates an expired entry while others wait or receive the stale copy) and bypass rules that exclude logged-in users, carts and other personalised responses from the shared cache.

## Practical use cases

Microcaching shines on high-traffic dynamic sites with mostly anonymous visitors — news portals, blogs, product catalogues, event pages. Content still refreshes every few seconds, yet the application server renders each page a handful of times per minute regardless of how many thousands of visitors arrive. It also acts as a cheap shock absorber for viral traffic spikes, buying time before autoscaling or manual capacity changes kick in.

On a typical [VPS](https://nodea.io/en/glossary/vps) or managed server this is implemented with Nginx's proxy\_cache or fastcgi\_cache directives; full-page caching plugins in CMSs complement it by producing static HTML. The best results come from combining layers: microcache protects the backend globally, while application-level caching accelerates the specific queries that remain expensive.

### Is a few seconds of microcache really worth it?

Yes — the maths is dramatic. At 300 requests per second, a 5-second microcache means the backend renders the page once per window instead of 1,500 times. Users still see content that is at most a few seconds old, which is acceptable for most public pages.

## Related

- [Cache-Control](https://nodea.io/en/glossary/cache-control)
- [Varnish Cache](https://nodea.io/en/glossary/varnish-cache)
- [Redis](https://nodea.io/en/glossary/redis)
- [Memcached](https://nodea.io/en/glossary/memcached)
- [OPcache](https://nodea.io/en/glossary/opcache)

---

Languages: [pl](https://nodea.pl/pl/slownik-pojec/cache-i-microcache.md)  
Site index: [llms.txt](https://nodea.io/en/llms.txt)