Redis cache strategy is the set of rules that decides what your application caches, what it queues, how sessions and rate limits behave, what can be lost, and what must survive a restart.
For SaaS teams, the main architecture risk is not using Redis-compatible storage. It is letting one in-memory service quietly become the cache, queue, session store, lock manager, rate limiter, and source of truth without giving each role a different failure and recovery policy.
Raff provides Managed Valkey for Redis-compatible workloads. Teams that need host-level control can also self-host Redis or Valkey on Raff VM. If you are searching for a managed Redis service, the Raff product to evaluate is Managed Valkey.
Redis cache strategy: quick decision
| Workload | Typical Redis/Valkey role | Can ordinary eviction be acceptable? | What should remain durable elsewhere? |
|---|
| Read cache | Rebuildable query/API results | Usually | Source records |
| Session store | Shared web sessions | Depends on session policy | Account/auth source of truth |
| Rate limiter | Counters and windows | Carefully | Security/audit state when required |
| Queue | Background jobs and retries | Usually no | Business outcome and idempotency state |
| Stream | Ordered event processing | Depends on retention | Authoritative business record where required |
| Lock | Duplicate-work prevention | Expiry is part of design | Protected business state |
| Counter | Operational or product counters | Depends on importance | Authoritative values when loss is unacceptable |
The core rule is simple: cache data should be rebuildable, queue work should have a recovery policy, and customer/business records should have a durable source of truth.
This page owns the architecture decision for Redis cache, Redis queues, sessions, rate limiting, and Redis-compatible Valkey workloads. For the broader SQL/NoSQL model decision, use SQL vs NoSQL for SaaS Apps. For managed-vs-self-hosted ownership, use Managed vs Self-Hosted Databases.
Redis caching works best with rebuildable data
A Redis cache is most useful when the application can reconstruct the cached value from a durable source.
Good cache candidates include:
- expensive database query results;
- profile or permission lookups;
- product and plan metadata;
- API response fragments;
- dashboard summaries;
- feature/configuration values;
- search/filter results;
- short-lived computed state.
Poor cache candidates include the only copy of:
- invoices and payments;
- subscriptions and entitlements;
- orders;
- user-generated content;
- audit records;
- durable file metadata;
- irreversible workflow state.
A common cache-aside pattern is:
Application
-> check Redis-compatible cache
-> cache hit: return value
-> cache miss: query primary database
return result
populate cache
Every cache key should have four documented answers:
- Source of truth: where can this value be rebuilt from?
- Freshness: how stale may it become?
- Invalidation: what event expires or refreshes it?
- Failure behavior: what happens when the cache is unavailable?
A high cache-hit ratio is useful only when the cached result is still correct. For memory-pressure behavior, review Redis eviction policies before choosing which keys may be removed.
TTL and invalidation matter more than simply adding Redis
Adding Redis does not automatically make an application faster or safer.
A cache strategy needs an expiry and invalidation model that matches the data.
Common approaches include:
- fixed TTL: simple, but can return stale values until expiry;
- event-driven invalidation: refresh or delete keys when source data changes;
- write-through/write-behind patterns: useful in some architectures, but increase consistency responsibility;
- versioned keys: useful when deployment or configuration versions should naturally invalidate older entries;
- short TTL + lazy refill: practical for rebuildable summaries when temporary staleness is acceptable.
The right choice depends on how expensive stale data is.
A cached marketing page can often tolerate short-lived staleness. A cached permission decision or account entitlement may need a much tighter invalidation path.
Redis queues need durability, retries, and idempotency
A Redis queue is a different reliability problem from a read cache.
Queues move slow, asynchronous, or failure-prone work away from the user request path. Common jobs include:
- email delivery;
- webhooks;
- imports and exports;
- report generation;
- media processing;
- billing workflows;
- search indexing;
- AI or batch jobs;
- scheduled work.
A production queue should define:
- retry count;
- retry delay/backoff;
- timeout;
- dead-letter or failed-job handling;
- idempotency key or duplicate protection;
- retention;
- worker concurrency;
- queue-depth alerts;
- recovery after restart or failover;
- what durable system records the final business outcome.
A safer pattern is:
User request
-> application writes durable business state
-> queue receives background work
-> worker processes job
-> durable database records final outcome
If a job is delivered twice, the business result should still be correct whenever possible.
Queue reliability therefore depends on the queue library, Redis/Valkey configuration, application idempotency, and the durable system that records the business result.
Cache and queue data should not share one failure policy
One Redis-compatible instance can technically serve several roles. That does not mean one memory and persistence policy fits all of them.
| Role | Typical failure tolerance | Design priority |
|---|
| Read cache | Loss often acceptable | Rebuildability and latency |
| Session store | Loss may log users out | TTL, availability, auth behavior |
| Rate limiter | Reset may affect abuse controls | Atomicity and failure mode |
| Queue | Pending work may be important | Retention, retry, recovery |
| Stream | Replay may be required | Retention and consumer state |
| Lock | Duplicate execution can matter | Safe expiry and idempotency |
If the cache uses aggressive eviction while a queue needs pending work retained, those workloads should not accidentally inherit the same assumptions.
At small scale, logical separation may be enough. As the roles become production-critical, separate instances can make memory, persistence, scaling, monitoring, and incident response easier to reason about.
Redis sessions need a deliberate logout and recovery policy
A Redis session store can centralize session state across several application instances.
Before using it, decide:
- session TTL;
- whether session loss may log users out;
- whether sessions can be rebuilt safely;
- multi-device behavior;
- tenant and environment isolation;
- what happens during failover;
- whether security-sensitive state also needs a durable audit record.
Session storage is often short-lived, but that does not make it operationally unimportant. A cache outage that only increases database load is different from a session-store outage that signs every user out.
Redis rate limiting needs a defined fail-open or fail-closed behavior
Redis-compatible systems are useful for rate limiting because counters, expiry, and atomic operations map naturally to common limiter algorithms.
Define the limit key first:
user:123:api:minute
account:456:exports:hour
ip:203.0.113.10:login:minute
Then decide:
- which identity is limited: user, account, API key, IP, or endpoint;
- fixed-window, sliding-window, token-bucket, or another algorithm;
- whether a store outage fails open or closed;
- whether a reset affects billing, security, or abuse controls;
- whether security-critical events also need durable logging.
Failing open may preserve availability but temporarily weaken the limit. Failing closed may protect the control but can block valid traffic. The right choice depends on the endpoint and business risk.
Locks need safe expiry and duplicate-work protection
Distributed locks are useful when multiple workers might try to perform the same operation, but a lock is not a replacement for application correctness.
Define:
- lock owner identity;
- maximum lock lifetime;
- renewal rules if the operation can exceed the TTL;
- what happens after process failure;
- whether duplicate execution is safe;
- whether a database uniqueness constraint can enforce the invariant more reliably.
If running the operation twice can charge a customer twice, send duplicate irreversible work, or corrupt state, the application should not depend only on the lock existing.
Use idempotency and durable constraints where possible.
Persistence changes the recovery promise
Redis-compatible systems can persist in-memory state, but persistence should match the role.
Redis and Valkey support snapshot- and append-log-oriented persistence models depending on version and configuration. A self-hosted deployment gives the team direct control of those settings, but also makes the team responsible for disk capacity, persistence files, backup, restore testing, upgrades, and incident response.
Managed Valkey reduces host-level operations, but the application still needs to decide whether its state is disposable, recoverable, or business-critical. For self-hosted persistence trade-offs, see Redis RDB vs AOF.
Do not use persistence as justification for turning a cache into the only copy of customer data.
If loss of the dataset would create irreversible customer impact, reassess whether PostgreSQL, MySQL, Object Storage, or another durable system should own the authoritative state.
Operational insight from Raff: for Redis-compatible workloads, Raff's review starts by separating disposable cache state from queue, session, or workflow state that needs a recovery policy.
Valkey vs Redis compatibility: what matters for Raff buyers
Valkey is a Redis-compatible open-source database that uses the RESP protocol. Its migration documentation describes compatibility with Redis OSS 7.2 and earlier open-source versions, including compatible protocol behavior and persistence formats for those versions.
Version-specific persistence compatibility still matters. Valkey documents that Redis Community Edition 7.4 and later data files are not directly compatible with Valkey data files, so teams should verify the source version and migration method instead of assuming every deployment can be moved by copying persistence files.
Existing Redis client libraries that support Redis OSS 7.2 generally work with Valkey, but production migration should still validate:
- client library and version;
- commands used by the application;
- Lua scripts or modules if applicable;
- authentication and TLS settings;
- cluster behavior;
- persistence expectations;
- queue and session framework behavior;
- failover handling.
For this guide, Valkey vs Redis is a compatibility consideration rather than the primary topic. The application architecture still needs separate rules for cache, queues, sessions, rate limiting, and durability.
Managed Redis buyer intent maps to Raff Managed Valkey
Teams often search for managed Redis when what they need is a hosted, Redis-compatible in-memory service.
Raff's deployable product is Managed Valkey. It is the managed Raff path for Redis-compatible caching, sessions, queues, pub/sub, and related workloads.
Raff Managed Valkey currently has a permanent $0 free tier with 512 MB memory, 2 GB storage, and up to 500 connections. Paid Valkey plans start at $7.99/month.
Use Managed Valkey when:
- reducing host maintenance matters;
- the workload is production-important;
- controlled connectivity matters;
- reducing recurring database-host operations matters;
- the application does not require unusual host-level customization.
Use self-hosted Redis or Valkey on Raff VM when:
- root or OS access is required;
- custom server configuration is a real requirement;
- exact upgrade timing must be controlled;
- custom modules, agents, or topology are required;
- the team can own persistence, monitoring, patching, backup, restore, and incidents.
The choice is the value of host control versus the ongoing operations your team must own.
Keep Redis-compatible services off broad public exposure
Redis-compatible databases should not be publicly exposed simply because the application can connect over TCP.
A production path should use supported access controls, TLS, credentials, and private connectivity where appropriate.
A common architecture is:
Internet
-> HTTPS application
-> controlled/private network path
-> Managed Valkey
-> primary database
For self-hosted Redis or Valkey, the team owns firewall rules, service binding, authentication, TLS where configured, patching, and host monitoring.
Production and non-production environments should also be separated so development traffic or keys cannot affect customer workloads.
Separate workers when queue load competes with web traffic
Queues become more valuable when background workers can scale and fail independently from request-serving application processes.
Consider separate worker capacity when:
- queue depth grows during traffic spikes;
- exports or reports consume significant CPU or memory;
- retry storms affect web requests;
- worker deploys should not restart the web tier;
- media, AI, or batch jobs need different resources;
- scheduled jobs create predictable load bursts.
For example:
Application workload
-> Managed Valkey queue
-> Worker workload
-> Managed PostgreSQL/MySQL
-> Object Storage
The queue coordinates work. The durable database stores customer or business state. Raff Object Storage stores file-like outputs that should not live in cache memory.
Production checklist for Redis and Valkey workloads
Before the Redis-compatible layer becomes production-critical, verify:
If the team cannot explain what happens when the Redis-compatible layer restarts or becomes unavailable, its production role is not fully designed yet.
Conclusion
A Redis cache strategy should define what can be rebuilt, what may be temporarily lost, and what needs a recovery path before the team chooses an infrastructure model.
Use Redis or Valkey caching for rebuildable data. Treat queues, sessions, rate limits, streams, and locks as separate reliability decisions. Keep durable business state in the appropriate authoritative database or storage system.
On Raff, Managed Valkey is the managed Redis-compatible path. Self-host Redis or Valkey on Raff VM when host-level control is a genuine requirement and the team is prepared to own the operating model.
Sources
