Cache Pattern Primer

Why caching matters

Every uncached request to your origin costs latency and compute. Meridian sits between your users and your backend, absorbing repeat reads so your servers only handle writes and true misses. The result is sub-5ms p95 latency for cached responses.

The three tiers

Cache keys & variance

Meridian derives cache keys from the normalized request: method, host, path, and any headers you whitelist. Avoid high-cardinality keys — every unique Authorization header creates a separate cache entry. Use cookie-based session tokens and strip them from the key instead.

Stale-while-revalidate

When a cached response exceeds its TTL, Meridian serves the stale copy immediately while asynchronously refreshing from origin. The next request gets the fresh value. This eliminates the thundering-herd problem and keeps latency predictable even during origin slowdowns.

Purge strategies

Soft purge marks entries as stale without deleting them, so stale-while-revalidate can still serve. Hard purge removes the entry entirely. Tag-based purging lets you invalidate entire groups — e.g. product:123 — with a single API call.