Caching / Cache

cache · caching · cacheing · ttl · cache invalidation · http cache · edge cache

Definition

Caching is the storage of intermediate computation or request results to speed up repeat access; the TTL, or cache lifetime, sets the balance between how current the data is and how much load the system carries.

How caching works

A cache is intermediate storage sitting between a data source and its consumer. On the first request the data is computed or fetched from the source and the result is written to the cache. On any repeat request the system answers from the cache — with no trip to the database, the API or the compute engine.

Every cache has two key parameters:

TTL (time to live) — how many seconds before an entry is treated as stale and dropped
Cache invalidation — forced clearing when the underlying data changes

Caching layers in e-commerce

Layer	Where	What is cached
CDN	Edge servers (Cloudflare, Fastly)	Static assets: JS, CSS, images, HTML pages
Application cache	Redis, Memcached	Query results: recommendations, prices, stock
In-memory	The service’s own RAM	Hot data with near-zero latency
Client-side	LocalStorage, Cache API	Content for offline use, prefetching

For a personalization platform the application cache is the critical one — it holds the prepared user vectors and the precomputed recommendation lists.

TTL in personalization: freshness against load

TTL = 0 min   → every request hits the API, maximum freshness, high load
TTL = 5 min   → the balance: recommendations age slightly, load drops 10–20x
TTL = 60 min  → fine for static blocks such as bestsellers and new arrivals
TTL = 24 h    → only for data that rarely changes, such as category top lists

Important: personalized content cannot be cached by URL alone — it needs segmentation by a user identifier such as a cookie or session ID. Otherwise user B is served user A’s cache.

Caching and A/B tests

One of the most frequent conflicts: the CDN caches a page without regard to which test group the visitor is in. The result is that every visitor sees variant A, although half of them should be seeing variant B.

The fixes:
– Use Vary: Cookie or Vary: X-AB-Group in the response headers
– Run the test through server-side rendering that resolves the group before caching
– Move the variable block out of the CDN cache and load it asynchronously through JS

Common mistakes

Caching personalized content as if it were shared — the visitor is served somebody else’s recommendations
Too long a TTL for a fast-moving catalogue — a recommended product is already out of stock but still on display
No invalidation strategy — a price change does not propagate until the next TTL expiry
A cache with no warming — right after a deploy the first visitors get every answer from the source and latency spikes

Frequently asked questions

What TTL is right for a recommendation cache?

It depends on how fast the catalogue and user behaviour move. For homepage recommendations 15–30 minutes is usually enough. For session-based recommendations such as recently viewed or cart-based blocks, the TTL should not exceed the length of a session, otherwise the visitor is served a stale result.

What is cache invalidation and why is it hard?

Cache invalidation is the forced clearing of cached entries when the underlying data changes. The difficulty is that in a layered system one SKU can be cached in several places at once — CDN, Redis, in-memory. Invalidating all of them in step without losing performance is a non-trivial problem.

Does caching affect A/B tests?

Yes, critically. If a page or widget is cached at the CDN without regard to which test group the visitor belongs to, every visitor gets the same variant. The rule: personalized content must never be cached at CDN level without segmentation by the group cookie or header.

How does a server-side cache differ from a client-side one?

A server-side cache such as Redis or Memcached holds data on the server and answers faster for every user. A client-side cache such as LocalStorage or the Cache API in a service worker holds data on one visitor's device and keeps working on a weak connection or offline.