Why a cache clear can expose a bigger problem
A store may behave well for hours, then slow sharply after a catalogue import or broad cache purge. Several requests can arrive for content that is no longer cached, causing expensive regeneration work to overlap. This pattern is often described as a cache stampede. It is a hypothesis to test against timing and workload, not a diagnosis that follows automatically from one slow first request.
The operational concern is the burst of backend work. Even pages that normally receive few visits can contribute when a large set of cache entries is invalidated together. If PHP workers or database capacity are already busy, the regeneration wave may affect dynamic journeys such as checkout. The right response depends on what is being invalidated, how requests are coordinated and where the workload waits.
Distinguish four different cache symptoms
A cache miss means a particular response was not served from that cache at that time. A cacheability problem means a response may not be eligible to be stored or reused as expected. An invalidation problem concerns when stored content is removed or marked stale. A stampede concerns concurrent work rebuilding content. These conditions can coexist, but they call for different evidence.
Start with the full-page cache guide if pages never appear to benefit from caching. Use this guide when there is a repeatable burst around cache expiry, invalidation or deployment. If the service is running out of memory, also review Redis memory problems; low memory and concurrent regeneration are not interchangeable explanations.
- 01InvalidateA cache entry becomes unavailable
- 02ConvergeRequests miss the same useful entry
- 03RegenerateConcurrent work puts pressure downstream
- 04StabiliseControl the cause and verify recovery
Build the timeline around the purge
Record when the import, deployment or administrative action started, when invalidation occurred and when slow requests began. Include the time zone and the source of each timestamp. Compare backend request volume, cache hits and misses, worker utilisation, database activity and customer-facing errors over that same interval. The shape of the change matters more than a screenshot of one high metric.
Look for a return to normal as content is repopulated, and whether the pattern recurs after the next related action. An increase in traffic at the same time can explain part of the effect, so keep visitor activity and campaign launches in the timeline. A single correlation is a starting point; controlled reproduction in a safe environment provides stronger evidence.
Identify the real cache layers and their owners
Document the installed stack: edge cache, reverse proxy, application page cache, other application caches and session storage. Not every Magento store has every layer, and different Magento releases and hosting platforms use different backends. A dashboard labelled “Redis” does not establish whether the affected data is page cache, general cache or customer sessions.
Do not flush session storage as a performance experiment. Do not assume an empty application page-cache directory means caching has failed when a reverse proxy is responsible for responses. Adobe distinguishes shared public content from customer-specific state; proposed caching changes must preserve that boundary. The goal is efficient work without leaking private information or serving incorrect commercial data.
Find what causes broad invalidation
Review the modules, import schedules and administrative operations associated with the event. A product update may legitimately invalidate related pages, but the relevant scope should be understood. Repeated whole-cache clears in an integration or operational script can erase the benefit of an otherwise effective cache. Ask why each invalidation exists before removing it.
Incorrect invalidation can also leave old prices or stock visible. Therefore, a narrower invalidation strategy needs correctness tests as well as performance tests. Update a representative product and check the category, product page, price context and customer journey that should change. Document the expected freshness. “Never invalidate anything” is not an acceptable performance solution for a trading store.
| Pattern | Question to investigate |
|---|---|
| Persistent misses | Is the response cacheable in this customer context? |
| Misses after frequent updates | What invalidates the affected content? |
| Concurrent misses after expiry | Do requests regenerate the same entry at once? |
| Backend pressure without misses | Is unrelated workload consuming shared resources? |
| Different public and logged-in behaviour | Is private state being handled as intended? |
Consider coordination and warm-up only after measuring
Some reverse proxies support request coordination or serving suitable stale content while a refresh happens. The precise behaviour depends on the platform and configuration. Ask the hosting or application owner to inspect the supported mechanism and its limits. Do not copy a grace-period configuration from a different stack and assume it is safe for personalised or rapidly changing content.
A controlled warm-up can help selected public pages after a release, but it is itself traffic. Prioritise important URLs and contexts, set a bounded rate, and stop if backend health deteriorates. Warming every conceivable filter combination can create more work than real shoppers would. It should not become a tool for hiding a page that is excessively expensive to generate.
Reduce the cost of rebuilding important pages
Even good cache coordination eventually needs to produce a fresh response. Profile the slow misses and identify unnecessary repeated work, expensive catalogue operations or external calls. A lower regeneration cost can improve both recovery after invalidation and ordinary cache-miss journeys. Confirm that the proposed improvement retains price, stock and customer-context correctness.
Where categories are the main source of misses, use the category performance guide. If workers queue across many routes, follow the PHP-FPM saturation guide. These linked investigations help separate the triggering event from the component that becomes the bottleneck under the extra work.
Test the recovery path, not only the warm state
In an authorised representative environment, compare a normal warm period with a controlled invalidation and recovery period. Agree the workload, metrics, maximum test intensity and stop conditions first. Observe critical dynamic journeys during recovery, not just the first cached page. Record how long the disturbance lasts and whether errors or queues remain afterwards. Use our Magento load-testing guide to define representative journeys, safe limits and the evidence to collect.
Include a content-correctness check. A test that looks fast because it serves an outdated promotion or the wrong customer-group price has failed the business requirement. Repeat a representative content update and verify that the intended pages change. The acceptance record should state both performance behaviour and freshness constraints, with any staging-to-production limitations made explicit.
Turn the pattern into a useful investigation brief
For a Magento Performance Investigation, provide the recurring action, approximate times, affected URLs and known cache stack. You do not need to prove a stampede before asking for help. Explain the observed pattern and distinguish what you measured from what you suspect. Access-dependent analysis belongs in the agreed internal scope.
If cache events are currently taking the store offline, use emergency support to assess containment first. A planned investigation can follow once trading is stable. Avoid repeated manual purges while waiting: they may remove evidence and restart the same expensive rebuilding cycle.
Common questions
Is a slow first request always a cache stampede?
No. A single slow miss can simply be expensive generation. A stampede involves overlapping regeneration work. Compare concurrency and the event timeline before applying that label.
Should we keep old pages cached for much longer?
Only if the freshness requirements and cache implementation support it safely. Product, pricing and customer-context correctness must remain part of the decision. A longer lifetime is not a universal repair.
Can a warmer overload the store?
Yes, a warmer sends requests that may reach the backend. Treat it as a bounded workload with monitoring and stop conditions. Test its behaviour before relying on it during a busy release.
Technical references
Use the documentation that matches your installed version, payment provider and deployment.