Fast page delivery directly drives revenue in ecommerce: just 100 milliseconds of added load time can hurt conversion rates by 7% (Akamai). This is exactly where Redis comes in. As an in-memory cache, Redis answers in the millisecond range: in the vendor benchmark, 99.76% of requests were served within one millisecond (Redis Docs) – instead of expensive database queries that take many times longer. For Shopware 6, Redis can be used as an HTTP cache, object cache, and session store, cutting load times noticeably. This guide shows how to configure Redis as a central cache layer in Shopware, master cache invalidation and warmup, run it in a cluster, and optimize hit rates deliberately – aligned with high-performance hosting.
Why Redis Makes Sense as a Cache Layer in Shopware
Shopware 6 is built on Symfony and uses a multi-layered caching system. By default, many cache entries end up in the filesystem. That works but scales poorly: file access is slower than memory access, and with multiple web servers behind a load balancer there is no shared cache. Redis is an in-memory key-value store that keeps data directly in RAM, making it ideal for frequently accessed, easily regenerated data.
The speed difference is substantial: while a database query can cost double- to triple-digit milliseconds depending on complexity, Redis served 99.76% of requests within one millisecond in the vendor benchmark (Redis Docs). Multiplied across dozens of queries per page view, this adds up to noticeably shorter response times – and thus better Core Web Vitals and higher conversion rates.
In-Memory Speed
Redis served 99.76% of requests within one millisecond in the vendor benchmark (Redis Docs) – far faster than file or database access.
Shared Cache in a Cluster
Multiple web servers access the same Redis. A prerequisite for auto-scaling during traffic peaks without inconsistent caches.
Measurable Effect
Shorter load times through in-memory caching and the removal of session locks at checkout.
An important distinction: Redis does not replace the database. The MySQL or MariaDB database remains the reliable source of truth. Redis is the fast intermediate layer that intercepts recurring read access. On a cache hit, Redis serves the data instantly; on a cache miss, the request falls back to the database, the result is computed and then stored in Redis. This exact flow is illustrated in the architecture diagram above.
HTTP Cache, Object Cache, and Session: The Three Layers
Shopware has several cache areas serving different purposes. The most important for performance is the HTTP cache (full page cache): it stores the fully rendered HTML page. When the same page is requested again, the cache serves it without PHP, Twig rendering, or the database ever becoming active. This is an important performance lever for high-traffic category and product pages.
The object cache sits one level deeper: this is where results from the Data Abstraction Layer (DAL) land, meaning prepared product data, configurations, and entities. When Shopware needs product information, it checks this cache first. Finally, the session and cart store holds user-specific data. Sessions in particular benefit from Redis, because file-based PHP sessions have a well-known problem: session locking.
| Cache layer | Content | Redis data type | Eviction policy |
|---|---|---|---|
| HTTP cache | Rendered HTML pages | Ephemeral (regenerable) | volatile-lru |
| Object cache (DAL) | Product data, entities | Ephemeral (regenerable) | volatile-lru / allkeys-lru |
| Session | Login, preferences | Aging (with TTL) | allkeys-lru |
| Cart / number ranges | Critical data | Persistent (RDB + AOF) | volatile-lru |
File-based PHP sessions lock the session file during a request. If two parallel requests from the same user arrive, the second must wait until the first releases the lock. Instead of running side by side, the response times add up. At checkout with parallel AJAX requests, this is noticeable. A shared session store in Redis mitigates this behavior and is a prerequisite for running multiple web servers.
Not every request is cacheable. The HTTP cache mainly applies to anonymous visitors and static page sections; as soon as user-specific content like a filled cart or a logged-in customer area comes into play, those parts are loaded dynamically or excluded from caching. Shopware solves this via so-called ESI fragments and cache cookies that separate dynamic areas from the static page. For configuration this means: the more cleanly dynamic and static content are separated, the larger the share of cacheable requests – and the higher the resulting hit rate.
Configuring Redis for Shopware 6
Redis is connected via Shopware's YAML configuration, switching the individual cache adapters to Redis. The official Shopware documentation explicitly recommends using separate Redis instances for different tasks, because current Redis versions can only apply a single eviction policy within one instance (Shopware Docs).
# Example assignment of separate Redis instances
shopware:
cache:
redis_url: 'redis://cache-redis:6379/0?persistent=1'
framework:
cache:
app: cache.adapter.redis
default_redis_provider: 'redis://cache-redis:6379/0'
session:
handler_id: 'redis://session-redis:6379/0'
# Critical data (cart, number ranges)
# in its own instance with RDB + AOF persistenceIf a cache instance is set to noeviction, Redis rejects write operations once maxmemory is reached – Shopware then throws errors and the shop can go down. For ephemeral caches, volatile-lru or allkeys-lru is recommended. Equally critical: a missing maxmemory limit. Without a limit, Redis grows until the host's RAM is exhausted – in the worst case, the Linux OOM killer terminates the MySQL process. And: Redis and swap do not mix – a swapping Redis instance is slower than direct MariaDB access.
A common configuration mistake is using a single shared Redis instance for cache, sessions, and carts. This causes resource contention: cache data competes with session and cart data for memory. When eviction kicks in, active carts may be deleted – customers lose their items at checkout. When switching to a Redis cart, the command bin/console cart:migrate is also required, otherwise existing carts are lost.
maxmemory_human:1.00G
maxmemory_policy:volatile-lru
Cache Invalidation: Fresh Data Without Losing Performance
The central challenge of any cache is: how does the served data stay fresh without losing the performance advantage? Shopware solves this through tag-based invalidation. Every cached response is tagged with cache tags identifying all entities used during the request. When a product changes, only the cache entries with the matching tag are invalidated – not the entire cache.
Since Shopware 6.7, invalidation is also delayed: cache deletions no longer happen immediately on save but are collected and processed via the message queue – by default every 5 minutes (Shopware Docs). This prevents many small changes from permanently clearing the cache and destroying the hit rate. According to the documentation, anyone using Redis should also place the delayed invalidation store on Redis; the MySQL adapter is intended only as a fallback (Shopware Docs).
- Tag-based instead of global – only invalidate affected entries; the rest of the cache stays warm
- Delayed invalidation – collect changes and process them in bundles (default: every 5 minutes, Shopware 6.7)
- Mind the reverse proxy – with an upstream CDN or Varnish, the cache must be purged there too
- Check stock changes – inventory and prices often need tighter invalidation than static content
In practice, balance is decisive: invalidation that is too aggressive constantly empties the cache and renders it ineffective, while invalidation that is too sluggish serves outdated prices or stock levels. For most shops, the delayed, tag-based strategy is a good middle ground. For time-critical data such as remaining stock, an additional, targeted invalidation of those specific entities is advisable.
Cache Warmup: Avoiding Cold Caches
An empty cache after a deployment, an invalidation, or a restart means the first visitors hit a cache miss and have to wait for the full computation. Under high traffic, many simultaneous misses can briefly put heavy load on the database – an effect known as a cache stampede. Cache warmup prevents this by rendering the most important pages in advance and writing them to the cache.
Shopware provides the command bin/console cache:warmup for this. The previously used command http:cache:warm:up has been deprecated since Shopware 6.5/6.6; instead, pre-warming via external crawlers that process the sitemap is recommended (Shopware Docs). In practice, warmup is typically automated right after a deployment so that production visitors hit warm caches from the start.
An automated cache warmup after every deployment ensures that the highest-revenue pages – homepage, top categories, bestsellers – come from the cache on the very first request. Experience shows it pays to focus warmup on the most-visited URLs rather than rendering the entire catalog. This keeps warmup duration manageable and avoids overloading the database with the warmup itself.
Redis in a Cluster: Shared Cache for Multiple Servers
As soon as a shop runs on more than one web server – for load distribution or failover – a shared cache becomes mandatory. If each server kept its own filesystem cache, inconsistent states would arise: server A serves an updated page, server B a stale one. A central Redis solves this because all web servers access the same store. This is precisely why Redis is a fundamental prerequisite for auto-scaling during traffic peaks.
For cluster operation, Shopware distinguishes three data categories (Shopware Docs): ephemeral data (caches, regenerable at any time), aging data (sessions, with decreasing relevance), and critical data (carts, number ranges, not regenerable). Ephemeral data needs no persistence; aging and critical data, by contrast, should be secured via snapshots (RDB) and append-only files (AOF) so they survive a restart.
Ephemeral Data
HTTP and object cache. Regenerable at any time, no persistence needed, volatile-lru as policy (Shopware Docs).
Aging Data
Sessions. Assigned a TTL, allkeys-lru, secured via RDB snapshots against data loss (Shopware Docs).
Critical Data
Cart, number ranges. Not regenerable – RDB + AOF persistence and volatile-lru are essential (Shopware Docs).
For high-load scenarios, the documentation also recommends connection pooling via the persistent=1 parameter in the DSN to reduce connection overhead (Shopware Docs). For very large shops, Redis cluster or replication can additionally make sense to distribute read load and increase failover safety. The concrete topology depends on the traffic profile and availability requirements – a point closely intertwined with the hosting architecture.
It is important to distinguish Redis from an upstream reverse proxy: Redis caches inside the application, while a reverse proxy like Varnish or an edge cache at global locations sits in front of it and serves whole pages before the request even reaches the web servers. Both layers complement each other: the edge cache intercepts the bulk of anonymous access, while Redis accelerates the dynamic requests that get through. With multiple cache layers, it is essential to synchronize invalidation across all of them so that no layer serves stale content.
Optimizing Hit Rate: Making the Cache Measurable
The most important metric of any cache is the hit rate – the share of requests served directly from the cache. In our project work, a value above 80% counts as healthy. For static content, 95–99% is achievable; for dynamic content, 85–90% is realistic. The higher the hit rate, the less often the database has to work – and the faster and more stable the shop runs under load.
The hit rate can be read directly from Redis. The command redis-cli INFO stats provides the values keyspace_hits and keyspace_misses, from which the hit ratio can be calculated. When the hit rate drops, typical causes are: invalidation that is too aggressive, a maxmemory that is too small (so entries are evicted prematurely), or a cold cache after frequent deployments. Continuous performance monitoring makes these effects visible.
# Calculate hit rate from Redis statistics
redis-cli INFO stats | grep keyspace
# keyspace_hits:1840233
# keyspace_misses:96518
#
# Hit rate = hits / (hits + misses)
# = 1840233 / 1936751 = 95.0%A high hit rate pays off immediately on business metrics: the more requests are served from the cache, the lower the server load and the more stable delivery stays even during load peaks. The path there runs through sensible TTLs, adequately sized memory, a measured invalidation strategy, and consistent warmup – four levers that together determine the cache's effectiveness.
The choice of TTL (time to live) deserves special attention. A lifetime that is too short lets entries expire before they are reused – the hit rate drops. A TTL that is too long risks stale content as long as no targeted invalidation kicks in. In practice, a tiered approach works well: static page sections and rarely changed master data get long TTLs, while frequently changing data such as stock levels get short ones. This is complemented by maxmemory sizing: if memory is too tight, Redis evicts entries prematurely and the hit rate collapses – even with perfectly set TTLs. Memory size, TTL, and invalidation must therefore be considered together, ideally accompanied by continuous monitoring of the metrics.
Caching as the Foundation for Fast, Scalable Shops
The data is clear: speed is directly revenue-relevant in ecommerce. Just 100 milliseconds of delay can hurt conversion rates by 7% (Akamai), and even a 0.1-second improvement in mobile load time increased the retail conversion rate by 8.4% and the average order value by 9.2% (Deloitte). Redis is an effective tool for achieving this speed in Shopware.
Clean implementation is decisive: separate Redis instances per data type, correctly set eviction policies and maxmemory limits, tag-based, delayed invalidation, automated warmup after every deployment, and hit-rate monitoring. Misconfigurations – a shared instance, noeviction, missing memory limits – can do more harm than good and, in extreme cases, take the shop down.
Caching has a cumulative effect: each additional cache layer relieves the one below it, and every hit-rate optimization amplifies the effect. For growing shops with expanding assortments and seasonal load peaks, a well-thought-out Redis architecture is therefore not an optional extra but the basis for fast pages, a stable checkout, and a smooth customer journey. As an agency focused on Shopware and high-performance hosting, we support you with configuration, cluster operation, and the ongoing optimization of your caching layer.
This article is based on data and recommendations from: Shopware Documentation (cache architecture, eviction policies, separate instances, delayed invalidation, warmup), Redis Documentation (latency benchmark), Akamai (conversion effect of a 100-millisecond delay), and Deloitte / Google (Milliseconds Make Millions, mobile load time and conversion). The hit-rate guide values come from our own project work. The figures cited can vary depending on hardware, configuration, and traffic profile.
Frequently Asked Questions About Redis Caching in Shopware
No. Redis is a fast intermediate layer, not the source of truth. The MySQL or MariaDB database stays authoritative; Redis intercepts recurring read access and serves it very quickly on a cache hit – in the vendor benchmark, 99.76% of requests were served within one millisecond (Redis Docs). On a cache miss, the request falls back to the database, the result is computed and then stored in Redis.
That depends heavily on the starting point, hardware, and configuration. In-memory caching cuts load times noticeably because recurring read access no longer reaches the database. The HTTP cache is usually particularly effective for frequently accessed category and product pages.
Current Redis versions can only apply one eviction policy per instance (Shopware Docs). A shared instance leads to resource contention: when eviction kicks in, active carts or sessions may be deleted and customers lose their items at checkout. Separate instances allow the appropriate policy and persistence per data type.
For ephemeral caches (HTTP, object), volatile-lru or allkeys-lru are suitable. For critical data such as number ranges, volatile-lru protects entries without a TTL from deletion. The noeviction policy should be avoided for caches because Redis then rejects writes once maxmemory is reached – which can cause shop errors.
Using redis-cli INFO stats you can read keyspace_hits and keyspace_misses; the hit rate is hits divided by (hits plus misses). In our project work, a value above 80% counts as healthy; for static content, 95–99% is achievable, and for dynamic content, 85–90% is realistic.
After a deployment or invalidation, the cache is initially cold, so the first visitors experience a cache miss. An automated warmup via bin/console cache:warmup or a sitemap crawler renders the most important pages in advance and writes them to the cache (Shopware Docs), so production visitors hit warm caches from the start.