Projektowanie kluczy cache i łączenie żądań

A cache key uniquely identifies a cached entry. When a request arrives, the cache computes its key and looks for a matching stored response.

• Same key equals a cache hit
• Different key equals a separate entry (or a miss)
• Poor key design causes low hit ratios or wrong responses

By default many caches key on the full URL including host and path. But query strings, headers, and cookies can also be part of the key, which dramatically affects how often you get hits.

Tracking parameters like utm_source create needless cache fragmentation. Strip or ignore irrelevant query params so equivalent requests share one entry.

The Vary header tells caches to store separate copies per header value. Useful for content negotiation but dangerous if overused: Vary: User-Agent can explode into thousands of entries.

Cookies often make responses uncacheable because each user has a unique cookie. Strip cookies for static assets, and only include the specific cookies that truly change the response.

Sometimes you intentionally vary by device class or country. Add a small, controlled dimension to the key (like a normalized device type) rather than the raw header to keep cardinality low.

• Good: mobile vs desktop
• Bad: full User-Agent string

When a popular item expires, many requests can simultaneously miss and hammer the origin at once. This thundering herd can overwhelm a backend during peak traffic.

Request coalescing (also called collapsed forwarding) makes the cache send only one request to the origin for a given key while other concurrent requests wait for that single fetch.

To smooth expiry, serve slightly stale content while a background refresh runs. This avoids both the herd and a latency spike for users.

In a Redis plus CDN plus edge stack, keep cache keys consistent across layers so they agree on what is the same object. Mismatched keys cause duplicate storage and confusing invalidation.

A solid cache key strategy:

• Strip tracking and irrelevant params
• Vary only on headers that change the response
• Avoid keying on raw cookies or User-Agent
• Enable coalescing for hot keys
• Use stale-while-revalidate to hide refresh latency

You learned how cache key design controls hit ratios: normalizing query strings, using Vary carefully, and avoiding high-cardinality dimensions. You also saw how request coalescing and stale-while-revalidate protect the origin from thundering-herd spikes across a multi-layer cache.