Fast page delivery directly drives revenue in ecommerce: just 100 milliseconds of added load time cost Amazon 1% in sales (Amazon), and a one-second delay reduces conversions by up to 7% (Akamai). This is exactly where Redis comes in. As an in-memory cache, Redis serves data with sub-millisecond latency and over 100,000 operations per second (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 by up to 40% (Hosted Power). 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: in comparative measurements, an in-memory cache serves read operations up to 80 times faster than a relational database (AWS). While a database query can cost double- to triple-digit milliseconds depending on complexity, Redis typically responds in the sub-millisecond range (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 delivers 100,000+ operations per second at sub-millisecond latency (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
Up to 40% shorter load times through in-memory caching (Hosted Power) 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 the biggest 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 finishes. In practice this means: instead of both requests completing in about 350 ms, the second takes 700 ms because it waits for the lock to be released (ma.ttias.be). 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 (Kickbyte). 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 (Kickbyte). And: Redis and swap do not mix - a swapping Redis instance is slower than direct MariaDB access (Kickbyte).
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 (Kickbyte). When switching to a Redis cart, the command bin/console cart:migrate is also required, otherwise existing carts are lost (Kickbyte).
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. A value above 80% is generally considered healthy (Kickbyte). For static content, 95-99% is achievable; for dynamic content, 85-90% is realistic (Gcore). 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, the most common 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. Analyses show that a hit rate of around 95% significantly reduces server load and thus enables near-instant page delivery even during load peaks (SurferCloud). 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. 100 ms of delay cost Amazon 1% in sales (Amazon), one extra second up to 7% fewer conversions (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 one of the most effective tools 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 (Kickbyte).
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 (throughput and latency benchmarks), Amazon (100 ms revenue effect), Akamai (conversion effect of delay), Deloitte / Google (Milliseconds Make Millions, mobile load time and conversion), AWS (in-memory vs. database read speed), Kickbyte (Redis configuration mistakes in Shopware), Gcore and SurferCloud (cache hit ratio benchmarks), ma.ttias.be (PHP session locking). 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 in the sub-millisecond range on a cache hit (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 can typically cut load times by up to 40% (Hosted Power), and read operations are up to 80 times faster than the database (AWS). The biggest effect usually comes from the HTTP cache 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 (Kickbyte). 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 (Kickbyte).
Using redis-cli INFO stats you can read keyspace_hits and keyspace_misses; the hit rate is hits divided by (hits plus misses). A value above 80% is generally considered healthy (Kickbyte); for static content, 95-99% is achievable, and for dynamic content, 85-90% is realistic (Gcore).
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.