Redis
Redis and high-availability replication
Redis deployments for caching, session storage and queueing. A replicated configuration stops the cache layer from being a single point of failure.
- Very low access latency
- In-memory
- Redundant cache layer
- Replication
- AOF and RDB options
- Persistence
- Open only to the app segment
- Isolated network
What happens when the cache layer goes down?
Redis is often deployed as a single instance on the assumption that it is "just a cache — if it drops we read from the database." In practice that assumption rarely holds: when the cache fails, every request hits the database at once and the database cannot absorb the spike. A cache failure turns into a database outage.
If session data lives in Redis the picture is worse: when the instance drops, every user is logged out. Technically that is not data loss, but to a user it is indistinguishable from an outage.
So for systems using Redis on the critical path we recommend a replicated deployment. When the primary fails the replica takes over and the cache layer stays up. Persistence settings are configured to the scenario too: unnecessary for pure caching, but required for session and queue data.
- Replication makes the cache layer redundant
- Persistence configured per use case
- Memory limit and eviction policy set explicitly
- Redis reachable only from the application segment
- Memory usage and connection counts monitored
Features
Use cases
Query caching
Results of expensive database queries are held in memory so repeat requests never reach the database.
Session storage
Shared sessions across multiple application servers, giving consistent behaviour behind a load balancer.
Queues and job lists
A lightweight queue for background jobs, with worker servers consuming it to free the web tier.
Rate limiting
Used as a request counter to enforce endpoint rate limits, reducing abuse and attack impact.
Replication
The replica takes over when the primary fails, so the cache layer is no longer a single point of failure.
Memory monitoring
Memory utilisation and eviction rate are tracked so approaching the capacity limit is noticed early.
FAQ
Frequently asked questions
Should I enable persistence in Redis?
It depends on the use case. As a pure cache, losing the data is harmless and persistence can stay off. If you hold session data or queues, persistence is needed so a restart does not lose it.
What happens when memory fills up?
The eviction policy decides. Removing least-recently-used keys suits caching scenarios, but with session data the wrong policy can log users out. We configure the policy to match how you use it.
Can I run Redis on the same machine as the application?
Possible in small deployments, but they compete for memory. Redis is memory-hungry, so when the application's memory needs grow both suffer. Because traffic between separate servers runs on the private network, separating them costs almost no latency.
More
Related pages
- Managed DatabasesManaged database servicesManaged database services covering deployment, configuration, backup, monitoring and version management. NVMe storage with replication over a 10 Gbps private network.
- High AvailabilityHigh availability (HA) architectureHA architectures with single points of failure removed: per-component redundancy, a defined failover scenario and regular rehearsals.
- E-CommerceE-commerce infrastructureAn e-commerce architecture with separated web, cache and database tiers. Planned pre-campaign scaling, redundant Redis caching and always-on DDoS protection.
Let's plan your infrastructure together
Tell us what you need and we prepare a configuration and pricing specific to you. We don't sell fixed packages; we build the deployment, licensing and backup plan with you.