Managed Redis
Assistance-operated Redis for cache, sessions, queues, rate limits, and real-time data paths
Managed Redis is for teams using Redis as a production dependency: cache, session store, rate limiter, lightweight queue, pub/sub channel, or real-time data structure. Assistance operates the Redis runtime so your engineers can focus on application behavior and performance.
Best-fit use cases#
| Use case | Why Redis fits |
|---|---|
| Application cache | Reduce database pressure and improve read latency for hot data |
| Session storage | Centralize session state for horizontally scaled applications |
| Rate limiting | Track counters and windows with low-latency operations |
| Queues and background jobs | Use lists, streams, or sorted sets for lightweight work coordination |
| Real-time features | Pub/sub, leaderboards, counters, and ephemeral state |
What Assistance operates#
| Area | Included managed service responsibility |
|---|---|
| Provisioning | Redis topology selection, memory sizing, network placement, secure defaults, and connection details |
| Reliability | Sentinel or Cluster design, replication health, failover procedure, persistence choices, backup options, and runbooks |
| Performance | Latency, memory, command, slow log, eviction, and connection monitoring |
| Maintenance | Patch planning, version lifecycle guidance, maintenance windows, and controlled restarts |
| Security | TLS options, ACLs, password/secret rotation support, network isolation, and audit-friendly access practices |
| Observability | Dashboards and alerts for memory pressure, latency, replication lag, persistence errors, and connection saturation |
| Support | Severity-based support for platform incidents and escalation for covered production services |
Redis behavior is a shared design decision
Assistance operates Redis, but your application owns key design, TTLs, cache invalidation, queue semantics, and whether data can be safely evicted. We help choose safe platform defaults, but application data semantics must be explicit.
Ownership boundary#
| Responsibility | Assistance owns | Customer owns |
|---|---|---|
| Runtime operations | Configure, monitor, patch, scale, back up where applicable, and operate Redis | Client usage, connection pooling, key design, and command patterns |
| Durability | Implement agreed persistence and backup approach | Decide which data is cache-only, recoverable, or business-critical |
| Eviction | Configure selected policy and monitor pressure | Define TTL strategy and acceptable behavior when memory fills |
| Availability | Operate Sentinel/Cluster/failover inside agreed topology | Application retry behavior and idempotency for Redis-dependent flows |
| Access | ACL model and rotation procedure | User approval, service credentials in applications, internal reviews |
Deployment options#
| Option | When to use it |
|---|---|
| Assistance physical servers | Development, staging, CI, internal tools, and predictable cache/session workloads |
| Customer cloud account | Production workloads needing low latency to application services or cloud network controls |
| Cache-only deployment | Performance optimization where data can be rebuilt from a source of truth |
| Durable Redis deployment | Queues, sessions, or stateful workflows that need persistence and recovery expectations |
Topology choices#
| Topology | Use when |
|---|---|
| Single node | Development, test, or non-critical cache-only workloads |
| Sentinel | You need HA failover for a single primary with replicas and manageable memory size |
| Redis Cluster | You need horizontal scale, higher write throughput, or data larger than a single node comfortably supports |
| Read replicas | You need read scaling or isolation for reporting/analytics-style consumers |
Reliability and support model#
| Topic | Managed Redis approach |
|---|---|
| Availability | Defined by topology and support tier; not all cache-only environments require production SLA language |
| Persistence | RDB, AOF, hybrid, or no persistence selected based on data semantics |
| Recovery | Restore expectations documented where persisted Redis is part of production recovery |
| Performance | Memory pressure, latency, and eviction are monitored because Redis failure is often capacity-driven |
| Response | P1 response targets scoped in the support plan; 24/7 critical response available for covered production services |
Onboarding#
1. Workload classification#
We classify Redis usage: cache, session, rate limit, queue, pub/sub, streams, or mixed. This determines durability, topology, and operational risk.
2. Configuration design#
Assistance defines memory sizing, persistence, eviction policy, topology, network access, ACLs, monitoring, and support model.
3. Integration and migration#
We provision Redis, provide connection details, help migrate keys where needed, and validate application connection pooling and timeout behavior.
4. Operate#
We monitor latency, memory, command rates, replication, persistence, and failover signals. Capacity changes are planned before memory pressure becomes an outage.
Not included by default#
- Designing every application cache key and invalidation path
- Rewriting queue consumers or job processing logic
- Guaranteeing durability for data declared cache-only
- Unlimited memory, node count, or retention outside the plan
- Debugging application-level race conditions unless scoped separately
Related products#
- Managed PostgreSQL — Source-of-truth relational database commonly paired with Redis
- Managed MySQL — Relational backend for cache and session-heavy applications
- Managed Prometheus — Metrics and alerting for cache hit ratio, latency, and saturation
- SRE as a Service — Incident response, SLOs, and runbooks around Redis-dependent systems
Getting started#
Request a Redis assessment. We will classify your workload, define data durability expectations, choose Sentinel or Cluster where needed, and document ownership and support boundaries.
Request Redis assessment →Frequently asked questions#
Should we use Redis Sentinel or Redis Cluster? Sentinel is usually simpler for HA around one primary. Cluster is appropriate when data size or throughput needs horizontal partitioning. We choose based on workload and growth, not default complexity.
Can Redis be used for queues? Yes, but queue semantics must be explicit. Redis Streams can be a good fit for lightweight queues, while Kafka is usually better for durable replayable event streams.
Is Redis data always persisted? No. Cache-only workloads may disable persistence for performance. Sessions, queues, or stateful workflows usually need persistence and recovery expectations.
Who owns cache invalidation? Your application team owns invalidation logic and TTL choices. Assistance monitors and operates the Redis platform and can advise on safe patterns.
What happens when memory fills? The agreed eviction policy applies. We monitor memory pressure and recommend capacity or TTL changes before Redis reaches unsafe saturation.