What we use Redis for
In Shopware 6, Redis takes the object and HTTP cache as well as the sessions. That noticeably relieves the database, because basket and login state no longer run through tables that are written on every page view. In TYPO3, Redis takes over the caching framework backends. In our own Symfony applications we also use it as a transport for Symfony Messenger, so that imports, mail dispatch and ERP synchronisation do not hang inside the web request.
The typical case is a project with several application servers behind a load balancer. As soon as sessions must not live on a single machine, a shared store is needed, and Redis is the obvious route. The same goes for shops with many simultaneous hits on the same category pages. What it cannot solve: a cache only helps on the second request. The first stays as slow as the application builds it.
How we run Redis
Redis runs here in its own containers on the Proxmox cluster, separated by purpose. Cache and sessions do not share an instance, because they need different rules: a cache may discard entries, a session may not. That is exactly where many installations come apart. If maxmemory-policy is set to allkeys-lru and the sessions sit in the same database, baskets are simply evicted under load — and nobody finds the reason in the shop log.
Along with that go persistence settings, a fixed memory limit and monitoring of memory use, evicted keys and hit rate. Redis is also not reachable from outside, only on the internal network and with a password. At deployment we check that cache keys are versioned, so a release does not meet old structures. And when in doubt we clear selectively instead of discarding everything and letting the shop start cold.
When you do not need Redis
A single web server with modest traffic gets by without Redis. Sessions in the file system and the database cache are enough, and you save yourself another service that has to be monitored, updated and understood when it fails. Redis is often sold where a missing index was the real problem. Once the index was in place the query was fast enough — the cache would only have covered it up.
Our order is therefore: measure first, then repair the query or the code, then cache. Cache first and you move the problem to the day the cache is empty — after a deployment, after a restart, after a price change across the whole range. Then the full load hits an application that was never built for it. We would rather say so beforehand.