Redis for Application Developers: Caching, Rate Limiting and Queues

What Redis is good at

Redis is an in-memory data store with data structures such as strings, hashes, lists, sets, sorted sets and streams. Operations are fast and many are atomic, which makes Redis useful for shared, short-lived state across application instances. Data lives in memory, so capacity is limited and, depending on configuration, data may be lost on restart. Design each use with that in mind.

Caching with cache-aside

The cache-aside pattern keeps the database authoritative: read from Redis, fall back to the database on a miss and store the result with a time-to-live. Invalidate or update keys when data changes if users must see updates immediately. Include a version in key names so code changes do not read stale formats, and set a maximum memory with an eviction policy suited to caching, such as evicting least recently used keys.

value = redis.get(f"course:v2:{course_id}")
if value is None:
    course = db.load_course(course_id)
    redis.set(f"course:v2:{course_id}", serialize(course), ex=600)
else:
    course = deserialize(value)

Protect against stampedes, where many requests miss the same expired key at once and all hit the database, by adding a small random variation to expiry times or letting one request refresh the value while others use the stale copy briefly.

Rate limiting

Redis's atomic counters make simple rate limits straightforward. A fixed-window limit increments a key per user and time window, sets an expiry on the first increment and rejects requests above the limit. Sliding-window or token-bucket approaches smooth out bursts at window boundaries, typically implemented with sorted sets or small server-side scripts so the check and update happen atomically. Return HTTP 429 with information about when to retry, and choose keys carefully, such as user ID for signed-in users and IP address with care for shared networks.

Lightweight queues and background work

Lists and streams can hold background jobs: the web request adds a job, and a worker processes it. Redis Streams support consumer groups, acknowledgement and tracking of unprocessed messages, which makes recovery after worker crashes possible. Many job libraries build on Redis and handle retries, delays and visibility for you, which is usually preferable to building your own. For jobs that must never be lost, confirm the persistence configuration and consider a dedicated queue service.

Operate it safely

• Require authentication, enable TLS where traffic crosses networks and never expose Redis directly to the internet.
• Set memory limits and monitor memory use, evictions and hit rate.
• Set timeouts on Redis calls so a slow cache does not slow every request.
• Make the application degrade gracefully when Redis is unavailable.
• Avoid commands that scan all keys in production; use cursor-based scanning instead.

Checklist

• Each use of Redis has a clear purpose and failure plan
• Caches use cache-aside, TTLs and versioned keys
• Stampedes are mitigated for popular keys
• Rate limits are atomic and return useful 429 responses
• Queues use acknowledgement and retries, ideally via a maintained library
• Redis is authenticated, private, limited and monitored