Sanity GROQ CDN cache behavior under concurrent identical requests and rate-limit limits

Does the Sanity CDN coalesce concurrent identical GROQ requests?

Based on the current public documentation and observable behavior, Sanity’s edge CDN (api.cdn.sanity.io) does not guarantee request coalescing or deduplication for concurrent identical cache misses. Each request that finds no valid cached entry (or whose cached entry is considered stale) will independently trigger a fetch from the Content Lake origin. This means that under heavy concurrent load the origin may receive multiple identical requests, increasing latency and consuming more of the project’s rate‑limit budget.

How to tell whether a response came from the origin or from the CDN cache

Sanity does not expose a dedicated header that unambiguously distinguishes an origin fetch from a cached validation, but several response headers can be used as indirect indicators:

• Age – The number of seconds the object has been stored in a cache. A value of 0 (or a very small number) suggests the response was generated fresh for this request, while a larger Age indicates it was served from a cached copy.
• Cache‑Control – When the CDN returns a cached copy it will include directives like max-age=<seconds> derived from the staleness setting. A response with max-age=0, must-revalidate (or similar) often accompanies a fresh validation request to the origin.
• X‑Cache (if present) – Some deployments of the Sanity CDN add an X‑Cache header with values such as HIT, MISS, or STALE. Observing MISS strongly implies an origin fetch, whereas HIT indicates a cached response.
• Response latency – Origin fetches typically exhibit higher and more variable latency (tens to hundreds of milliseconds) compared to cached hits (often sub‑millisecond to a few milliseconds). Measuring latency across many identical requests can reveal a bimodal distribution when coalescing is absent.

Because these indicators are not guaranteed to be present in every response, the most reliable way to confirm behavior is to run a controlled test: send a burst of identical uncached requests and monitor the origin‑side metrics (e.g., Content Lake request count) or the rate‑limit headers.

Balancing staleness=0 freshness with concurrent load and rate limits

1. Apply client‑side deduplication – Before issuing a GROQ request, check whether an identical query is already in flight (e.g., using a request‑collapsing library or a simple memoization cache with a short TTL). This reduces the number of concurrent misses that reach the CDN.
2. Tune staleness according to freshness needs – If sub‑second freshness is not required, use a small positive staleness value (e.g., staleness=1 or staleness=5). This allows the CDN to serve a slightly stale cached copy while still respecting the configured freshness window, dramatically lowering origin traffic under load.
3. Monitor rate‑limit headers – Responses include X-RateLimit-Remaining and X-RateLimit-Reset. Track these values during load tests to stay comfortably below the threshold and implement exponential back‑off when X-RateLimit-Remaining approaches zero.
4. Implement retry with jitter – Should a 429 Too Many Requests be received, retry after the delay indicated by Retry-After (if present) or use an exponential back‑off with random jitter to avoid thundering‑herd effects.
5. Consider request batching or GraphQL‑style aggregation – Where possible, combine multiple logical queries into a single GROQ request (using parameters, filters, or projections) to reduce the total number of requests sent to the CDN.

In summary, the Sanity CDN does not currently provide guaranteed coalescing of identical concurrent GROQ requests. Applications should rely on client‑side deduplication, appropriate staleness tuning, and careful observation of cache‑related headers and rate‑limit signals to maintain freshness goals while staying within plan‑specific rate limits.