Photo: free stock photography (Unsplash licence) — see imprint
Cache-aside is your default
Read from Redis; on a miss, read the database, write it back with a TTL. It is simple, easy to reason about and survives a Redis outage — the shop just gets slower, not broken. Start here and only leave when you have a measured reason.
Never cache what must be correct
Stock levels, customer-specific prices and cart totals should be read live or cached for seconds, not minutes. A cached price that is 4% too low is not a performance win — it is a discount you did not authorise.
Beware the stampede
When a popular key expires, a thousand requests all miss at once and hit the database together. Use a short lock or serve the stale value while one worker refreshes. Most 'Redis made it worse' stories are actually stampede stories.
Tag your keys or regret it
When a product changes, you must be able to invalidate everything derived from it — listing, detail, search facet, sitemap. Without a tagging scheme you will end up flushing the whole cache, and then you have no cache at all.
- Cache-aside first; complexity only when measured.
- Prices and stock: seconds, never minutes.
- No tagging scheme, no real cache.
Frequently asked questions
Probably not yet. If your HTTP cache is not configured, Redis is the wrong problem to solve first — you would be adding a system to speed up work the shop should not be doing at all. Redis earns its place once pages are cached and you still have expensive repeated reads. Fix the cheap thing first; it is usually configuration, not infrastructure.
Usually a stampede. When a popular key expires, a thousand requests miss at once and hit the database together — so peak load gets worse exactly when you are watching. Use a short lock, or serve the stale value while one worker refreshes. Most stories that begin with 'Redis made it worse' turn out to end here.
Yes, and that is the failure mode worth fearing. Stock levels, customer-specific prices and cart totals belong live, or cached for seconds rather than minutes. A cached price that is too low is not a performance win — it is a discount nobody authorised, and a B2B customer will hold you to it. Cache what is stable; read what must be correct.
With cache-aside, nothing dramatic: the shop reads the database directly and simply gets slower. That is the entire reason we start there and only leave when a measurement says so. Clever patterns that make Redis a hard dependency turn one cache outage into a shop outage. Ask which of the two you are buying before choosing the pattern, not during the incident.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer