Redis Write Failures — Default Eviction Policy
OOM errors from default 'noeviction' policy: use MEMORY USAGE to detect session leaks and avoid late-night pager calls—debugging steps for production.
- Redis is a single-threaded, in-memory data structure server that operates in microseconds
- Uses RAM for storage — eliminates disk I/O latency (nanoseconds vs milliseconds)
- Core types: Strings, Hashes, Lists, Sets, Sorted Sets — each designed for a specific access pattern
- Key expiry (TTL) prevents memory bloat and ensures data freshness
- Production risk: default
noevictionpolicy causes write failures when memory fills up without warning
Imagine your brain vs a filing cabinet. When your teacher asks you the capital of France, you don't go rummaging through a cabinet — you just know it instantly because it's in your short-term memory. Redis is that short-term memory for your application. Your main database (PostgreSQL, MySQL) is the filing cabinet — thorough but slow. Redis sits in RAM, razor-close to your app, so fetching a value takes microseconds instead of milliseconds. It's a supercharged sticky-note board your entire server cluster can share.
Every high-traffic application hits the same wall eventually: the database becomes the bottleneck. A query that takes 40ms feels invisible during development but becomes catastrophic when 10,000 users hit it simultaneously. Twitter, GitHub, Stack Overflow, and Shopify all reached this wall — and Redis is a big part of how they broke through it. It's not an exaggeration to say that understanding Redis is what separates junior developers from engineers who can design systems that actually scale.
Redis (Remote Dictionary Server) solves the read-amplification problem. Most web applications read data far more than they write it — a product page might be read 50,000 times a day but updated once. Hammering your relational database with 50,000 identical queries is wasteful and slow. Redis lets you compute the answer once, store it in memory, and serve all 50,000 requests from there in microseconds. But Redis isn't just a cache — it's a full data structure server that can power rate limiters, leaderboards, pub/sub messaging, session stores, and queues.
By the end of this article you'll understand not just what Redis commands look like, but WHY each data structure exists, WHEN to reach for each one, and how to wire Redis into a real application pattern. You'll also learn the subtle mistakes — wrong expiry strategies, cache stampedes, missing persistence configs — that trip up developers who learned Redis from a cheat sheet instead of from first principles.
Why Redis Lives in RAM and Why That Changes Everything
Traditional databases store data on disk. Disk access — even an NVMe SSD — operates in the microseconds-to-milliseconds range. RAM access operates in nanoseconds. That's not a small difference; it's three orders of magnitude. Redis keeps its entire dataset in memory by default, which is the single most important architectural decision behind its speed.
But speed isn't the only trick. Redis is single-threaded for command execution. That sounds like a limitation until you understand what it eliminates: lock contention. In a multi-threaded database, threads fight over the same rows with locks. Redis sidesteps that fight entirely — one command runs to completion before the next starts. This makes Redis operations atomic by default, which matters enormously for things like incrementing a counter or checking-then-setting a value.
Redis also supports optional persistence. You can tell it to snapshot its RAM contents to disk every N seconds (RDB snapshotting) or to log every write command to an append-only file (AOF). Most production setups use both. This means Redis isn't just a volatile cache — it can survive a restart and recover its data.
The practical takeaway: use Redis for data that is read far more than it's written, where milliseconds matter, and where you can tolerate the data being slightly stale or reproducible if lost.
entity:id:field — e.g., user:1001:display_name or session:abc123. This makes keys self-documenting and lets tools like RedisInsight group them visually. Never use flat keys like displayname1001 — you'll hate yourself when you have 2 million keys to debug.maxmemory and instantaneous_ops_per_sec in production; never use KEYS in app code.Redis Data Structures — Picking the Right Tool for Each Problem
Redis isn't just a key-value store in the boring sense. It stores five core data types, and choosing the right one is the difference between an elegant solution and a painful hack.
Strings — the default. Good for counters, cached HTML, serialized JSON blobs, and session tokens. The INCR command atomically increments a string-as-integer, making it perfect for rate limiting and hit counters.
Hashes — think of a Hash as a mini dictionary attached to one key. Instead of storing a user as one giant JSON blob, you store their fields separately. This lets you update a single field without fetching and re-serializing the entire object.
Lists — ordered, duplicates allowed. Built on a linked list internally. Ideal for queues (push to the tail, pop from the head) and activity feeds (push new events to the head, trim the list to keep only the last N).
Sets — unordered, unique members. Perfect for tracking unique visitors, tagging systems, or finding common followers between two users with SINTER.
Sorted Sets — the crown jewel. Every member has a floating-point score. Redis keeps members ordered by score automatically. This is how you build leaderboards, priority queues, and range-based queries without a single SQL ORDER BY.
The Cache-Aside Pattern — Wiring Redis Into a Real Application
Knowing Redis commands is one thing. Knowing how to integrate Redis into your application code without creating subtle bugs is another. The most widely-used pattern is Cache-Aside (also called Lazy Loading). The logic is elegantly simple: when your app needs data, check Redis first. If it's there (a cache hit), return it immediately. If it's not (a cache miss), fetch it from the database, store it in Redis with a TTL, then return it. Redis never gets data pushed to it — your application pulls it through.
This pattern is powerful because it's self-healing. If Redis goes down and loses all its data, your app degrades gracefully — everything just goes to the database until Redis is warm again. The cache populates itself organically based on what users actually request, not what you predict they'll request.
The critical detail most tutorials skip: always set a TTL. Without one, your cache grows forever and you'll eventually run out of RAM. More importantly, stale data lives forever. If a product's price changes in your database but the Redis entry never expires, customers see wrong prices indefinitely. Your TTL is your freshness guarantee.
The code below shows this pattern implemented in Python with the redis-py library — the same library used by Instagram and Pinterest in production.
Redis Expiry, Eviction and Why Your Cache Will Betray You Without Them
TTLs are your first line of defense against stale data. But what happens when Redis runs out of memory before any keys expire? This is where eviction policies come in, and most developers don't think about them until Redis starts refusing writes in production — which is a very bad day.
Redis has several eviction policies configured via maxmemory-policy in your redis.conf. The default policy is noeviction — Redis refuses new writes when full. That sounds safe but it means your application starts throwing errors. For a cache, you almost always want allkeys-lru (evict the least recently used key across all keys) or volatile-lru (evict the least recently used key that has a TTL set).
There's also the cache stampede problem — also called the thundering herd. Imagine 500 concurrent users all request the same popular product page. The cache entry expires at the exact same moment. All 500 requests find a cache miss simultaneously and all fire a database query at once. Your database gets hammered with 500 identical queries in the same millisecond. The fix is probabilistic early expiration or using a mutex lock in your cache-miss path so only one request rebuilds the cache while others wait.
The rule of thumb: if your cache powers any page that gets high traffic, you need to think about stampedes. If your cache serves data with truly random access patterns, you probably don't.
maxmemory-policy noeviction by default. If you don't set a maxmemory limit AND an eviction policy before going to production, one of two things happens: Redis eats all available RAM until the OS kills it, or Redis fills up and starts returning COMMAND errors to your application. Always set maxmemory and maxmemory-policy allkeys-lru in your redis.conf before deploying. Check it now — seriously.Redis Persistence — RDB vs AOF and Production Trade-offs
By default, Redis stores everything in RAM. If the server restarts, all data is lost. For a cache, that's acceptable. But many teams use Redis as a session store, a rate-limiter state store, or even a primary database for high-frequency writes. In those cases, losing data on restart is catastrophic.
Redis offers two persistence mechanisms:
RDB (Redis Database) — periodic snapshots of the entire dataset to disk. You configure how often (e.g., save 900 1 means if at least 1 key changed in 900 seconds, save). RDB files are compact and great for backups/disaster recovery. The downside: you lose data between snapshots. A crash 10 minutes before the next snapshot loses 10 minutes of writes.
AOF (Append Only File) — logs every write command to an append-only file. You can replay the file on restart to reconstruct the dataset. AOF gives you finer granularity: you can configure appendfsync everysec (lose at most 1 second of writes) or always (every write forces disk sync, near-zero data loss but 30-50% slower writes).
Most production setups use both. Redis supports a combined mode: RDB for fast restores, AOF for durability. When both are enabled, Redis loads the AOF on restart because it's more complete.
The choice matters for your data loss tolerance. Session stores need AOF everysec. Cache layers don't need persistence at all. A leaderboard that can rebuild from database can afford RDB-only. Match the persistence config to your data's criticality.
- RDB: Low overhead, fast recovery, but data loss window (up to your save interval). Best for cache layers and scenarios where data can be rebuilt.
- AOF: Higher overhead (especially appendfsync always), but sub-second data loss. Best for session stores, rate limiters, critical counters.
- Both: Use both for maximum safety. Redis prioritizes AOF on restart. The small disk cost is worth the peace of mind.
- Production trap: AOF with appendfsync always can cause write latency spikes during disk syncs. Test with your write throughput before enabling.
The Late-Night Pager: Redis Write Failures from Default Eviction Policy
maxmemory-policy config.maxmemory-policy noeviction combined with a memory leak from unbounded session storage. When Redis hit the maxmemory limit (set to 48 GB via monitoring tool), it refused all writes. No key had a TTL, so no keys expired. The leak was caused by a session table that never cleaned stale sessions.maxmemory-policy allkeys-lru in redis.conf, added TTLs to session keys (EXPIRE 3600), and configured memory alerting at 80% of maxmemory. Ran CONFIG SET maxmemory-policy allkeys-lru as a live fix, then bounced the service to clear memory.- Always configure
maxmemory-policybefore going to production — never rely on defaults. - Every SET command must include a TTL unless the key is truly permanent (and documented).
- Set memory usage alerts at 70% and 85% of maxmemory — don't wait for OOM errors.
- Use
MEMORY USAGEandMEMORY STATSin production monitoring to detect leaks early.
INFO memory to see used_memory_human vs maxmemory. Temporarily increase maxmemory with CONFIG SET maxmemory 2gb, then permanently fix the eviction policy and memory leak.SLOWLOG GET 10 to find slow commands. Check CLIENT LIST for long-running connections. Verify network latency between app and Redis with redis-cli --latency.INFO evicted_keys. If evicted_keys > 0, the maxmemory-policy is evicting keys. Review maxmemory setting and add TTLs where missing. Also check for FLUSHDB/FLUSHALL in slowlog.INFO expired_keys. If many keys share the same TTL, you have a cache stampede. Use random TTL jitter (±20%) on SETs to spread expiry times. Also check if a deployment cleared cache via FLUSHALL.redis-cli ping. If fails, verify systemctl status redis, check logs at /var/log/redis/redis-server.log. Ensure bind config allows app IP. Check firewall/security groups. redis-cli -h <host> -p 6379 PING from the app server.maxmemory 1gb and maxmemory-policy allkeys-lru. Restart Redis to apply.Key takeaways
Common mistakes to avoid
4 patternsNot setting a TTL on cached keys
Using KEYS * in production to find matching keys
SCAN 0 MATCH product:* COUNT 100 returns up to 100 matching keys per call and a cursor to continue from. Never use KEYS in production code.Storing large serialized objects as Strings and updating them non-atomically
Setting the same TTL for all cache keys in a high-traffic endpoint
ttl = base_ttl + random.uniform(-0.2base_ttl, 0.2base_ttl). This spreads expiry over time. Also consider probabilistic early expiration (refresh the cache when TTL < 10% of original).Interview Questions on This Topic
Redis is single-threaded — how can it handle thousands of concurrent connections without being a bottleneck?
Frequently Asked Questions
That's NoSQL. Mark it forged?
6 min read · try the examples if you haven't