Caching Cdn Standards

Caching and content delivery (CDN) standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Applies when deciding whether to cache, where to cache and who invalidates: in-process cache, distributed in-memory cache (Valkey/Redis used as a cache), HTTP response cache in the reverse proxy, and CDN. Covers caching patterns, key design and invalidation, the classic failures with names of their own, HTTP cache header semantics, edge configuration, cache-specific security risks and their measurement.

Triggers: Cache-Control, max-age, s-maxage, must-revalidate, private/no-store, stale-while-revalidate, stale-if-error, CDN-Cache-Control, Surrogate-Control, Surrogate-Key/Cache-Tag, Cache-Status, Age, Vary, purging and PURGE, origin shield, cache key and query string normalisation, edge function/Worker/Lambda@Edge, maxmemory, maxmemory-policy, noeviction, allkeys-lru, volatile-ttl, evicted_keys, keyspace_hits/keyspace_misses, proxy_cache/proxy_cache_path, cache-aside, read-through, write-through, write-behind, thundering herd, cache stampede, hit ratio, cache poisoning and web cache deception.

Thesis of the skill: caching is duplicating state, and all duplicated state goes out of sync. The right question is never "do I cache this?" but "what happens when it is stale and who invalidates it?". If there is no answer to the second, there is no cache: there is a time bomb with good latency. Uncomfortable corollary: the cache is the default solution to problems nobody has diagnosed — before adding a layer, measure what is slow and why (§6.4).

Not applicable: see data-platform-standards (parent skill: it sets Valkey (BSD-3, Linux Foundation) as the default cache engine over tri-licensed Redis 8+, and the basic TTL and cache-aside criteria. This skill goes deeper and does not contradict it: there the engine is chosen and the licence declared, here the eviction policy, the invalidation strategy and the behaviour under failure are decided), load-balancing-standards (the reverse proxy and the load balancer are theirs: HAProxy, nginx, Traefik and Caddy — choice, health checks, draining, TLS termination, topology and hardening; networking-standards is the trunk and already delegates that depth to them. Here only their role as an HTTP response cache: proxy_cache, cache key, coherence with the edge and with the origin. The boundary is clean: nginx as proxy and balancer → load-balancing-standards; nginx as cache → this skill), api-design-standards (the HTTP contract is theirs: mandatory ETag per resource, If-Match/If-None-Match, 412/428, 304, and the requirement to declare correct Cache-Control and Vary on every response. Here the behaviour of the infrastructure that consumes those headers: what the edge does with them, s-maxage vs max-age, CDN-Cache-Control, serve-stale and the cost of a badly set Vary on the hit rate. Do not duplicate ETag semantics: delegate them), message-brokers-standards (queues, brokers and distributed logs: Kafka/KRaft, RabbitMQ, NATS, Redpanda, Pulsar — and the rule that a PostgreSQL table with SKIP LOCKED is usually enough. Redis/Valkey Streams used as a queue falls on their side. Boundary declaration: the queue is theirs, the cache is mine; an instance acting as a cache does not act as a queue — they are workloads with different durability and HA, and they share a process only by accident), microservices-architecture-standards (data ownership, outbox, sagas), aws-standards/azure-standards/gcp-standards (CloudFront, Azure Front Door, Cloud CDN, ElastiCache/MemoryDB, Memorystore as managed services: their IaC, IAM, WAF and billing; here the caching criteria that apply the same whoever the provider is), cicd-standards (the CDN purge as a deployment step and asset versioning with a hash in the name), kubernetes-standards (Ingress and proxy deployment), cryptography-pki-standards (TLS and certificates at the edge), appsec-standards (threat methodology and general OWASP; here only the risk classes specific to caching), privacy-engineering-standards (personal data in cache: legal basis, minimisation and effective erasure including cached copies — here only the mechanics of purging them), observability-standards (metrics platform; here which cache SLIs to export), sre-practice-standards (SLOs and error budget), object-storage-standards (the static origin behind the CDN), mysql-mariadb-dba-standards and oracle-dba-standards (critical boundary: the cache usually exists because the database cannot cope. If the cause is an N+1, a query with no index or a badly chosen PK, the right answer is to fix the query, not to add a cache — §6.4), rag-standards/llm-app-engineering-standards (semantic caching of prompts and LLM responses: a domain of its own, with its own hit criteria), lua-standards (the platform belongs here —nginx/OpenResty and its configuration, upstreams, TLS, cache policy and purging; Redis/Valkey and its memory, persistence and eviction—; the Lua running inside is theirs: EVAL/EVALSHA scripts and their determinism, and the code of the access_by_lua/content_by_lua phases with its hard ban on blocking calls in the event loop), streaming-multimedia-standards (the video/audio pipeline is theirs —HLS/DASH packaging, segment duration, bitrate ladder, DRM—; here the CDN that serves those segments: an HLS segment is one more cacheable HTTP object, and its TTL, its headers and its egress cost are decided here), web-performance-standards (the cache policy, the CDN, the headers and the purge belong here; the effect measured on the client —LCP, TTFB at the 75th percentile, field data— is theirs. A cache that improves the hit ratio and does not move the user metric has solved nothing), pwa-standards (an operational warning, not just a boundary: a service worker's cache is another layer, in front of everything this skill decides, and it can override the cache policy of the CDN and the origin. A deployment that is not visible in the browser is usually a sw.js serving old HTML, not a purge failure. The criteria for that layer —what is precached, with which strategy and how a broken service worker is disabled— are theirs).

2. Default decisions

Verify the latest version, licence and real directive support on the web before committing to it in a project (§8). Data from August 2026.

3. Technical criteria

3.1 The layers, from the inside out

Rule: caching in the wrong layer multiplies the problem instead of solving it. Data personalised per user cached at the CDN is a data leak; global data cached in each pod is N divergent copies of something that should have been in one place. Put the cache in the outermost layer that is correct (most benefit) and never further out than that (most risk).

No-overlap rule: do not stack layers for the same data without deciding the relationship between their TTLs. Two caches with 300 s TTLs in series give a maximum staleness of 600 s, not 300.

3.2 Patterns

• Cache-aside (lazy loading) — the default. The application reads the cache; on a miss it reads the origin and writes the cache with a TTL. Advantages: simple, the cache is never on the critical write path, it survives its own outage. Cost: every miss pays the full latency, and there is a race window between reading the origin and writing the cache.
• Read-through: the cache (or its library) loads the data on a miss. It encapsulates better, but couples the application to a component that is now on the critical read path.
• Write-through: writes to cache and origin at once. Better coherence, higher write latency, and it fills the cache with data nobody may read.
• Write-behind (write-back): writes to the cache and persists asynchronously. Maximum performance and maximum risk: the cache holds the only copy of the data until it is flushed. Vetoed except with demonstrated durability of its own and an ADR accepting the loss.
• Invalidation on write: delete, do not update. A DELETE of the key after the write has fewer races than rewriting the value (two concurrent writers can leave the old value if they update). The next reader repopulates it.
• Proactive refresh (cache warming) only for a small, known and critical set (home page, featured catalogue). Pre-warming "everything" reproduces the load you were trying to avoid.

3.3 Invalidation: the hard problem

In order of preference:

1. By TTL — simple, self-limiting, no additional state, and sufficient in the vast majority of cases. There is only one design question: how many seconds of stale data does the business tolerate for this data? Put it in writing; it is usually much more than the team assumes, and quite a bit less than the default TTL reflects.
2. By event — the writer invalidates when the data changes. Correct and precise, but it introduces coupling and fails silently: when the event is lost, nobody notices. Hard rule: event-based invalidation is always combined with a TTL as a safety net, never replaces it.
3. By tag / surrogate key — when one change invalidates a set ("all the products in this category"). It is the right thing for the edge. Cost: maintaining the tag map and depending on the provider's proprietary mechanism (§2).
4. By version in the key — change the prefix and the old cache dies by eviction. Instant, atomic invalidation with no purging; in exchange, a 100% miss rate right afterwards. Combine it with warming the critical set or with a progressive rollout.

Governing criterion: prefer a short TTL to perfect invalidation. An event-based invalidation system is one more distributed system to maintain, debug and monitor, with its own class of bugs; a 30 s TTL has no bugs and often solves the same business problem. Raise the complexity only when the cost of the short TTL (load on the origin) has been measured and is unaffordable.

3.4 The classic failures with names of their own

• Stampede / thundering herd / dog-piling: a hot key expires and N concurrent requests hit the origin at once. Mitigations, combinable:
  • Locking or single-flight: only one requester recomputes; the rest wait or receive the stale value. The lock must have a mandatory expiry (if the one recomputing dies, it must not block everyone forever).
  • Probabilistic early expiration: when the entry approaches its expiry, a probabilistically chosen requester refreshes it in the background while the others keep serving the current value. It is the application-level equivalent of stale-while-revalidate.
  • Soft TTL / hard TTL: serves the value past the soft TTL while it is refreshed; it only blocks on reaching the hard one.
• Penetration (non-existent keys): requests for identifiers that never exist never hit the cache and always go to the origin — a trivial DoS vector. Mitigation: cache the negative result with a short TTL (an explicit marker, not an ambiguous null), validate the key format at the edge, and a Bloom filter for large key spaces.
• Avalanche (simultaneous expiry): a batch of keys created at the same time expires at the same time. Mitigation: mandatory jitter on every TTL (e.g. ttl * (1 + rand(0, 0.2))). Dangerous variant: cache restart or failover, which expires everything at once — the application must survive a 100% miss rate (§6.3). If it does not survive, the cache is not an optimisation: it is a hard dependency with no HA plan.

3.5 Key design

• Explicit, documented format: <app>:<format-version>:<entity>:<id>[:<variant>]. No spaces and no free user-supplied data without normalisation.
• The key includes everything that makes the value vary: identifier, language, currency, country, API version, role or segment if applicable. A forgotten dimension = serving the wrong content; in the HTTP layer, the exact equivalent is an incomplete Vary (§5).
• Version the value's format in the key. When you change the serialised shape, change the version: it is the only safe way to deploy N and N-1 at the same time without the new code reading old structures (or the other way round). Never reuse the same prefix with a different schema.
• Never put personal data or secrets in the key: keys appear in logs, metrics, traces and diagnostic output. Use an opaque identifier.
• Bounded cardinality: one key per combination of free user filters is a cache with a 0% hit rate and infinite memory pressure. Normalise and bound the key space before caching (the same applies to the CDN cache key, §3.8).

3.6 Valkey/Redis as a cache (not as a database)

The engine choice and its licence are set by data-platform-standards (Valkey by default, BSD-3; Redis 8+ tri-licensed). Here, operation in the cache role:

• maxmemory always set, below the container/host memory with headroom for fragmentation and replica and client buffers. Without maxmemory, the process grows until the OOM killer decides for you.
• maxmemory-policy:
  • allkeys-lru / allkeys-lfu → the default for a cache. LFU if there are persistently hot keys; LRU if the pattern is temporal.
  • volatile-* → only if data with and without TTLs coexist in the same instance. Trap: if they run out of candidates with TTLs, they behave like noeviction.
  • noeviction on a cache instance is an incident: once full, writes start returning an error (OOM command not allowed) and the cache stops accepting new entries while it keeps serving the old ones. It silently becomes a frozen, stale store. noeviction only makes sense when the instance is not a cache (queue, counters, locks) — and then it is another instance, with another skill (§1).
• Fragmentation: watch mem_fragmentation_ratio. Values well above 1 indicate memory held by the allocator; activedefrag is an option, at a CPU cost. Values below 1 mean swap — unacceptable in a cache: disable swap or size it properly.
• Persistence: disabled in the cache role. RDB causes memory spikes from fork (copy-on-write) and I/O spikes; AOF costs latency. Unless you want a warm start after a planned restart — a conscious decision, with its cost measured, not the default inherited from the package.
• The cache vs database difference, explicitly: a cache is rebuildable from the source of truth, at any moment and without loss. The moment a piece of data only exists there (a session with no backing, a business counter, a work queue), it is no longer a cache: it inherits durability, backup, HA and replication requirements — and it is probably in the wrong store.
• HA: replica and failover (Sentinel or cluster mode) only if the impact of losing the cache justifies it, measured against the question in §6.3. Cluster for datasets that do not fit in one node, not out of fashion. Before setting up HA for a cache, ask whether it is not cheaper to make the system tolerate its absence.
• Forbidden in production: KEYS (use SCAN), FLUSHALL/FLUSHDB from the application, long Lua scripts, and sharing the cache instance with queue or lock workloads.
• Security surface: never exposed to an untrusted network, TLS and authentication mandatory, administrative commands renamed or disabled. Watch the CVEs: 2026 has brought in this family DoS via the cluster bus and use-after-free with the possibility of RCE (including in the Lua scripting engine) — with minimum fix versions published per branch. Verify your branch against the current advisory (§8).

3.7 HTTP: the directives that really matter

Explicit delegation: the semantics of ETag, If-None-Match, 304, If-Match and 412, and the obligation to declare Cache-Control and Vary on every response, belong to api-design-standards. Here, what the infrastructure does with them:

• max-age vs s-maxage: max-age applies to all caches; s-maxage only to shared ones (proxy, CDN) and takes precedence over max-age in them. The useful pattern is a short max-age in the browser (cheap revalidation) and a long s-maxage at the edge (where you can purge).
• CDN-Cache-Control (RFC 9213, Targeted HTTP Cache Control): when the CDN must do something different from the other caches. It allows, for example, Cache-Control: no-store + CDN-Cache-Control: max-age=600 (the edge caches, nobody else). Careful: carrying two policies in the same response is a known source of confusion about where a sensitive piece of data ends up stored — document the intent.
• stale-while-revalidate and stale-if-error (RFC 5861) — the two that give the most value:
  • stale-while-revalidate=N: serves the stale value for N s while revalidating in the background. It turns the latency spike of expiry into zero, and is the "out of the box" stampede mitigation in the HTTP layer.
  • stale-if-error=N: serves the stale value if the origin returns an error or does not respond. It turns an origin outage into a degradation, not into an error page. It costs zero in normal operation: set it generously.
  • Verified status (August 2026): stale-while-revalidate is honoured by Chrome, Firefox and Edge; Safari does not. stale-if-error is not implemented by any major browser: it is effectively a CDN/proxy directive. At the edge: CloudFront supports both; Cloudflare made its SWR fully asynchronous in Feb-2026 (previously the first request after expiry blocked); Google Cloud CDN supports SWR but not stale-if-error (and applies serveWhileStale by default, 86400 s if unspecified); Fastly gives full control. "Serving stale" does not mean the same thing in two CDNs: verify yours (§8).
  • Mind the window: the asynchronous refresh only happens if a request arrives within the SWR window. With sparse traffic, a small window still leaves requests blocking.
• immutable for assets with a hash in the name: it avoids useless revalidations.
• private vs public vs no-store: private prevents storage in shared caches but not in the browser; no-store is the only one that prevents storing anywhere. Everything authenticated or personalised: no-store or private and a cache key that includes the user. Never public on a response that depends on the session.
• Vary: the directive that destroys the hit rate without warning. Each added value multiplies the stored variants by that header's cardinality.
  • Vary: Accept-Encoding → acceptable (2-3 variants).
  • Vary: Accept-Language → as many variants as the language strings browsers send (hundreds). Normalise to a closed set at the edge before varying.
  • Vary: User-Agent → forbidden: effectively infinite cardinality, hit rate ≈0. Use normalised client hints or a decision at the edge.
  • Vary: Cookie or Vary: Authorization on public content → veto: any analytics cookie fragments the cache per user. If the response depends on the session, it is not cacheable content in a shared cache (§5).
  • Omitting a necessary Vary is worse than including it: it is exactly the mechanism of data leakage between users (§5).
• Cache-Status (RFC 9211): the standard header for knowing which layer hit and why it missed (no Vary match, stale response, partial response…). Essential for debugging a low hit rate. In production, only to authorised clients: it reveals information about the cache key, useful to an attacker (§5).
• Age to detect real staleness in production, and to verify that the edge and the browser count freshness as you expect.

3.8 CDN

• What goes to the edge: static content (with a hash in the name → immutable), images and media, anonymous HTML responses, public read-heavy API responses. What does not: anything that depends on session, cookie or authorisation header, except with a cache key that explicitly includes the principal — and even then, with a security review (§5).
• Dynamic with a short SWR: for content that changes often but tolerates seconds of age (listings, home pages, read API responses), a low s-maxage + stale-while-revalidate + a long stale-if-error wins more than any other configuration.
• Cache key and normalisation — where the hit rate is won or lost:
  • Ignore irrelevant query parameters (utm_*, fbclid, gclid…): if they enter the key, every marketing campaign manufactures you an empty cache.
  • Sort and filter the query to an allowlist; normalise host case, trailing slash and path encoding.
  • Careful with aggressive normalisation: merging into the same key two URLs the origin treats differently is precisely the mechanism of parser-discrepancy poisoning (§5). Normalise the same way at the edge and at the origin, or do not normalise.
  • Headers and cookies out of the key except for an explicit list.
• Purging: by tag when the provider allows it, by path otherwise; by wildcard, only as a last resort (equivalent to flushing). Its real latency is not zero: propagation to all PoPs takes time, and in a large CDN a downed PoP may not complete it until it returns. Do not design flows that assume instant, global purging. The superior strategy is still not needing to purge: a hash in the asset's name and a version in the key.
• Origin shield: an intermediate layer that consolidates the misses from all the PoPs against the origin. It drastically reduces origin load and egress cost on long-tail content; it adds a latency hop on a miss and one more configuration point. Enable it when the origin suffers from the number of PoPs, not by default.
• Egress cost is a design criterion, not a billing surprise: the hit rate is a cost variable as well as a performance one. Every byte that misses is paid for twice (origin egress + CDN transfer), and most providers also bill per request and some for cache fill. The models differ at the root (per GB, flat fee with unmetered bandwidth, base fee + GB): a drop in the hit rate is a cost incident, and deserves an alert (§6.2). Model the cost before choosing a provider and review the terms of use: "unmetered" bandwidth plans usually exclude the mass distribution of video or large files.
• Edge functions (Workers, Lambda@Edge, edge middleware): use them to manipulate the cache key, normalise, redirect, add security headers and run A/B tests by controlled variant. Not for business logic or data access: it is a different execution environment, with a different deployment model, different observability and a different failure model. If it ends up having state, it is no longer an edge function: it is a service with no SRE.

4. Quality and CI gates

In increasing order of cost. The ones marked break the build:

1. Response header lint: every route declares an explicit Cache-Control; fail if an authenticated response lacks no-store/private, or if a public response includes Set-Cookie or depends on Authorization. Gate.
2. Veto on Vary: User-Agent, on Vary: Cookie over public content, and on public + Vary: Authorization. Gate.
3. Cache layer tests with a real cache (a Valkey container), not with an in-memory double: TTLs, eviction and network errors are precisely what has to be tested.
4. Invalidation tests as a happy path and as a failure: write → read stale → invalidate → read fresh; and the case where invalidation fails — the TTL must still bound the staleness. A cache system without this test is a system with no guarantee.
5. Edge case tests: miss, expiry, cached negative result, cache down (the application must degrade, not fail — §6.3), and a cache returning a value in an old format (key versioning, §3.5).
6. Stampede test: N concurrent requesters on a just-expired key generate one load on the origin, not N. It is the regression that most silently comes back.
7. Edge coherence test: authenticated request, purge, and verification that the personalised content does not appear in a subsequent anonymous request. Automatable against pre-production. Gate in the CDN configuration pipeline.
8. Review of the CDN configuration as code (Terraform or OpenTofu; see iac-standards), with a reviewed diff: edge configuration changes the security behaviour of the whole application and cannot be edited by hand in the console.
9. CDN purge as an explicit, verified deployment step (see cicd-standards), including the case where the purge fails.
10. Deception test in the security suite: request an authenticated route with an invented static suffix (/account/profile/x.css, .avif, .js…) and check that it is not cached (§5).

5. Cache security

The three risk classes are specific to this domain and appsec-standards does not cover them in this detail:

• Serving a personalised response to another user — it is a data leak, not a performance bug. It is the most serious and most frequent cache failure, and it appears through three routes: an incomplete cache key, a Vary that omits the personalising dimension, or a missing Cache-Control on an endpoint someone decided to cache further up. Treat it as a security incident with notification, not as a caching bug: if it happened, there was exposure of personal data (see incident-response-forensics-standards and privacy-engineering-standards). Defence by design: deny by default at the edge — nothing is cached except allowlisted routes; and automatic no-store in the presence of Authorization or a session cookie.
• Cache poisoning: the attacker gets the cache to store a manipulated response that is then served to everyone. Vectors: inputs not included in the key but reflected in the response (unkeyed headers such as X-Forwarded-Host, X-Forwarded-Scheme, query parameters ignored in the key but used by the application), and URL parsing discrepancies between the edge and the origin (trailing slash, encoding, delimiters) — a very active line of research: large-scale studies find thousands of affected sites and recurring bypasses of CDN protections. Mitigation: every input that influences the response is part of the key or is removed at the edge; identical normalisation at edge and origin; do not reflect non-normalised headers; restricted Cache-Status; and active tests in the security suite.
• Cache deception (web cache deception): the attacker induces the victim to request /account/profile.css; the origin ignores the suffix and returns the profile, the edge sees a "static" extension and caches it as public; the attacker retrieves it. Mitigation: the decision to cache is taken from the Content-Type and from the origin's policy, not from the URL extension; the origin sends Cache-Control: no-store on everything authenticated; and do not trust the provider's "protected" extension lists (bypasses with new or uncommon extensions have been demonstrated). Normalise or reject paths with unexpected suffixes.
• Poisoning via request smuggling and desynchronisation between the proxy and the origin: the vector that turns a parsing discrepancy into total control of the cache. It is a risk of the proxy↔origin chain (see networking-standards for the network piece and appsec-standards for the technique), but its amplification belongs to the cache: a poisoned response is served to thousands.
• Personal data in cache: the cache is one more copy of the data, subject to the same classification, encryption and retention. The right to erasure reaches cached copies: without the ability to purge selectively, the TTL is your only erasure guarantee — document it and bound it. Never personal data in the key (§3.5) or in the edge logs.
• DoS by cache: requests for non-existent keys (penetration, §3.4) and requests designed to maximise misses (random query) turn your CDN into an amplifier against your own origin — and into an invoice. Strict key normalisation, rate limiting at the edge and negative caching.
• Patching the cache and proxy software: 2026 has been a hard year on this surface (overflows in nginx with active exploitation in the wild, resource exhaustion via HTTP/2 affecting multiple proxies, use-after-free in the scripting engine of the Redis/Valkey family). The cache is on the path of all the traffic: its patching window is that of an edge component, not that of an internal service. See vulnerability-management-standards and networking-standards (proxy versions).
• Supply chain of the edge functions and the packages they bundle: they are deployed on the path of all the traffic. Pin by digest and verify signatures — remembering the 2026 precedent (Mini Shai-Hulud / CVE-2026-45321, forgery of SLSA level 3 attestations): provenance on its own is no longer sufficient proof.

6. Measurement and operability

6.1 SLIs per layer

No aggregate metric works: measure the hit rate per layer and per content class. A global 95% can hide a 99% on static assets and a 20% on the API, which is what hurts.

• Distributed (Valkey/Redis): keyspace_hits/keyspace_misses, evicted_keys (if it grows steadily, the cache is too small or the TTLs too long), expired_keys, memory used vs maxmemory, mem_fragmentation_ratio, p99 latency, blocked clients and rejected connections.
• HTTP/CDN: hit rate (per PoP and per content type), requests and bytes to the origin (the metric that translates into an invoice), latency at origin vs at edge, Age of the responses served, stale-serve rate (stale-while-revalidate / stale-if-error firing: a spike in stale-if-error is an origin-down alert disguised as normality), origin 5xx errors and purge rate.
• Business: perceived end-to-end p95/p99 latency — the only one that justifies the cache existing.

6.2 Alerts worth having

A sharp drop in the hit rate (a symptom of a deployment that changed the key, a new Vary or a mass purge — and also a cost incident); sustained growth of evicted_keys; memory approaching maxmemory; spikes of stale-serving on error; and deviation of egress spend from the baseline.

6.3 The question that defines your architecture

What happens if the cache disappears right now?

If the answer is "the system goes down", you do not have a cache: you have an in-memory database with no durability, no backup and no HA. Design so the application works degraded without the cache (rate limiting, controlled degradation, a circuit breaker towards the origin, progressive load while repopulating) and rehearse it: switching off the cache in a game day is one of the most profitable tests there is. Short timeouts towards the cache: a miss must cost milliseconds, never become the bottleneck it was meant to avoid.

6.4 The uncomfortable conversation: cache vs fixing the origin

Before adding any layer, answer in writing:

1. What exactly is slow? (trace and query plan, not intuition).
2. Is it a database problem or an application problem? An ORM N+1, a query with no index, a PK that fragments the clustered index or OFFSET pagination are fixed where they belong. Caching the result of a query with no index hides the problem, duplicates the state, adds a whole class of coherence bugs and leaves the bomb armed for the first mass miss. See mysql-mariadb-dba-standards §6 and data-platform-standards.
3. How much staleness does the business tolerate? If the answer is "none", no cache is possible: the origin has to be made faster.
4. Who invalidates and what happens if it fails? (§3.3).
5. Does the system survive without the cache? (§6.3).

Without the five answers, the cache is not designed: it is just installed.

6.5 A high hit rate with stale data is worse than a low one

The hit rate is not the success metric: it is the efficiency metric. A cache that hits 99% serving data from an hour ago that should have been 10 seconds old is working perfectly and doing harm, and it does so silently: it generates no errors, it fires no alerts and the user simply sees something false. Always measure the hit rate alongside the age served (Age, p95 staleness) and treat excessive staleness as a correctness defect, not a performance one.

7. Sustainability and prohibitions

• Every cache has an owner and a review date. Review twice a year: prefixes with no traffic, TTLs nobody remembers choosing, CDN rules inherited from a migration, automated purges against routes that no longer exist. A forgotten cache rule is active debt.
• Edge configuration is code: versioned, reviewed and deployed by IaC, with a pre-production environment of its own. Changing caching in the provider's console is vetoed.
• Document in an ADR: the CDN provider choice (a one-way door because of the coupling of the purge mechanism and the edge functions), the invalidation strategy and the placement of each layer.
• Portability: keep the application's cache logic provider-agnostic and concentrate the proprietary parts (surrogate keys, edge functions, VCL) in a thin, isolated layer, with the exit cost estimated.

FORBIDDEN

• ❌ Adding a cache without the five answers of §6.4. In particular, caching to cover up a query with no index or an N+1.
• ❌ Entries with no TTL, or a TTL with no jitter on batches created at the same time.
• ❌ Event-based invalidation with no backing TTL.
• ❌ noeviction (or volatile-* with no candidates) on a cache instance; an instance with no maxmemory.
• ❌ The cache as the only copy of a business datum; write-behind without durability of its own and an ADR.
• ❌ Sharing the cache instance with queues, locks or business counters.
• ❌ KEYS, FLUSHALL/FLUSHDB from the application in production.
• ❌ An authenticated or personalised response cacheable in a shared cache; public on content that depends on session or cookie.
• ❌ Vary: User-Agent; Vary: Cookie on public content; omitting a necessary Vary.
• ❌ Deciding cacheability by the URL extension instead of by the origin's policy (cache deception).
• ❌ Different key normalisation between the edge and the origin (parser-discrepancy poisoning).
• ❌ Personal data or secrets in the cache key, in the edge logs or in a publicly exposed Cache-Status.
• ❌ Designing on the assumption of instant, global CDN purging.
• ❌ An endpoint with no explicit Cache-Control ("the framework takes care of it").
• ❌ Business logic or data access in edge functions.
• ❌ Configuring the CDN by hand in the provider's console.
• ❌ Presenting the hit rate as a success metric without the age served (§6.5).
• ❌ Stating versions, licences or directive support from memory, without §8.

8. Mandatory web verification

Before committing to any version, licence, directive or provider behaviour:

1. Valkey: latest version and maintained branches (api.github.com/repos/valkey-io/valkey/releases — raw data, not the HTML of the releases page) and the licence verbatim from the

…(truncated)