Codewerk.
Get a quote
Home/Blog/Clearing Shopware caches properly (and why it 'came back')

Clearing Shopware caches properly (and why it 'came back')

There is no single cache. There are five, and the one you forgot is the one still serving yesterday's price.

Photo: free stock photography (Unsplash licence) — see imprint

The five caches

The application cache (containers, config), the Twig/template cache, the HTTP cache, the reverse proxy in front of it (Varnish or a CDN), and PHP's own opcache. Clearing one and declaring victory is how a 'ghost' price survives a deploy.

Clearing everything is not free

A full cache clear on a busy shop means every next visitor rebuilds pages from the database at once. Do it at a quiet hour, or warm the cache afterwards — a cleared cache at 10 a.m. on Monday is a self-inflicted outage.

Invalidate, do not flush

Shopware invalidates cached pages when the underlying entity changes. If you find yourself flushing everything after every price update, something is wrong with your invalidation — fix that instead of scheduling a nightly flush.

Deploy scripts, not a wiki page

Cache handling belongs in the deployment script, in the right order, every time. A checklist that a human follows at midnight will eventually be followed at midnight by a tired human.

Key takeaways
  • Five caches — the forgotten one serves stale prices.
  • Never full-flush during business hours.
  • If you must flush often, your invalidation is broken.

Frequently asked questions

Start by accepting there is no single cache. There is the application cache, the template cache, the HTTP cache, the reverse proxy or CDN in front of it, and PHP's own opcode cache. Clearing one and declaring victory is exactly how yesterday's price survives your deploy. Know which layer you are actually clearing, and in which order the layers sit.

Something further out is still holding it. Usually the reverse proxy or CDN sitting in front of the shop, sometimes the opcode cache on the PHP side. You cleared a layer the request never even reaches. Work outwards from the shop and check each layer separately — the one you forgot is by definition the one still serving the stale page.

You can, and on a busy shop it is a self-inflicted outage. Every next visitor rebuilds their pages from the database at the same moment, and the database was not sized for all of them at once. Do it in a quiet hour, or warm the cache afterwards before the traffic arrives. A full flush at 10 a.m. on Monday is a decision, not an accident.

No — that is treating a symptom you should be curious about instead. Shopware invalidates cached pages when the underlying entity changes. If you feel the need to flush everything after every price update, your invalidation is not working, and a nightly flush only hides that from you while buying you a cold cache every morning. Fix the invalidation instead.

We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.

Talk to an engineer

// Keep reading

Related articles