Production Engineering

Before you tune anything, know what you're building. Redis in production usually shows up in one of six shapes.

Redis has 200+ config directives. Ten of them decide whether your production instance is fast, durable, and predictable. Learn these; the rest are noise until you have a specific problem.

maxmemory + maxmemory-policy

Never run Redis without a maxmemory limit. If you don't set one, Redis will happily use all available RAM and get OOM-killed by the kernel — taking your cache offline. Set an explicit limit for the instance's role, and leave headroom for allocator / fragmentation overhead, replication and client output buffers, and fork() copy-on-write growth during persistence.

The policy decides what happens when you hit the limit. allkeys-lru evicts across all keys and can fit a disposable cache when recency is a good proxy for value. volatile-lru only evicts keys with a TTL — useful when you mix cache and persistent data in the same instance. noeviction returns errors on write instead of evicting — the correct choice when Redis is a source of truth, not a cache.

Persistence trio

save lines configure RDB snapshot triggers ("if N keys changed in M seconds"). appendonly yes turns on AOF. appendfsync everysec typically limits acknowledged-write loss to about a second, but it's a durability/latency trade-off rather than an unconditional guarantee. RDB + AOF is a reasonable choice for stateful or durability-sensitive roles; a pure cache may choose lighter persistence or none at all.

Dangerous commands

FLUSHALL wipes the entire dataset. KEYS * blocks the server for as long as it takes to scan every key and can create a meaningful stall on a large keyspace. CONFIG SET can change persistence, security, and memory limits at runtime. If your ops model allows it, disable or rename these as a defense-in-depth guardrail — but treat ACLs, authentication, and network isolation as the primary safety controls.

Security basics

Never expose Redis directly to the public internet. Put it on a private network, restrict which application nodes can reach it, and keep routine app access separate from administrative access.

Require authentication and ACLs. Give application clients the smallest command and key-pattern permissions they need, keep admin identities separate, and store Redis secrets in your normal secret-management path rather than config files or shell history.

Enable TLS anywhere Redis traffic crosses untrusted networks or shared infrastructure. Combine that with explicit control over dangerous commands (CONFIG, FLUSH*, DEBUG, KEYS) so emergency and debugging access is intentional instead of available to every client.

Redis is fast by default. "Redis is slow" is almost always a client-side or workload problem, not a Redis problem.

The three real bottlenecks

Slow commands. KEYS *, unbounded SMEMBERS, LRANGE 0 -1 on a million-item list, SORT on a big set — any command whose complexity is O(N) with a big N will block the single-threaded main loop. Everyone waiting is now stuck behind that one command. Use SCAN, bounded LRANGE, or model the data differently.

Big values. A single 100 MB string takes real time to serialize to the network. Redis P99 gets worse whenever any request touches a value that's much larger than the median. Keep values small — under a few hundred KB — or move the payload elsewhere and store only the reference.

Network round-trips. If your app does 100 sequential GETs to render a page, that's 100 network round-trips × 500µs each = 50 ms. The Redis server did 100µs of actual work. Pipeline those commands into one round-trip and the same page renders in 5 ms.

Pipelining and MULTI

MULTI / EXEC wraps a group of commands in a transaction — they run atomically as one unit on the server. Combine with WATCH for optimistic concurrency. Note that Redis transactions are not rolled back on individual command errors; they're atomic in the sense of "executed together with no interleaving", not "all-or-nothing on error".

Connection pooling

Opening a TCP connection to Redis takes far longer than serving a command. Use a client-side connection pool (every serious client library has one) and size it for your real concurrent usage. Too small and requests queue or time out; too large and you add connection overhead plus client-side head-of-line effects without creating more Redis capacity.

Redis does not have one universal scaling ladder. Pick the next topology based on which limit you are actually hitting.

When one bigger box is still the right answer

Buy a bigger box. Command execution is serialized through Redis's main thread, so faster cores beat more cores until you enable I/O threads for network-bound workloads. RAM is the other dimension — you can only cache what fits. A single well-sized modern instance can handle far more traffic than most teams expect before any sharding is needed; the actual ceiling depends on command mix, value sizes, and network conditions rather than a fixed number. Vertical scaling gets you further than you'd think.

When read pressure or HA is the next constraint

Add N read replicas. Route read traffic to replicas via a client-side load balancer; keep writes on the primary. This works when your workload is read-heavy (most caches, session stores, feature flags). Watch out for staleness — the tolerance for that varies by feature.

When blast radius and workload isolation matter

Split by domain. Sessions on Redis A, cache on Redis B, rate limits on Redis C. Each instance is smaller and independently managed. This is often a strong answer — it caps blast radius, lets each dataset have its own memory / persistence / policy, and doesn't require Cluster's constraints (no cross-slot commands, hash tags, etc.).

When one primary's write ceiling is the real limit

Horizontal write distribution. Data is split across N primaries using CRC16 slot hashing. Each primary has its own replicas. You gain more aggregate capacity, but you lose free-form multi-key operations — every command that touches multiple keys either uses hash tags to keep them on the same slot, or gets a CROSSSLOT error.

Redis is stunningly stable when idle. Almost every incident is triggered by a specific operational condition. These are the metrics that catch each one.

Memory

`used_memory` and `used_memory_rss`. Watch the ratio — if RSS is far larger than used, investigate fragmentation, allocator behavior, and recent workload changes before reaching for activedefrag. `used_memory_peak` gives you sizing input. Alert on memory trend and remaining headroom relative to the instance's eviction tolerance, rather than one fixed percentage for every deployment.

Ops throughput

`instantaneous_ops_per_sec`. If this drops suddenly and CPU is idle, something's blocking the main loop. If this drops and CPU is 100%, you're at throughput ceiling — pipeline, add I/O threads, or shard.

Slow log

Enable slowlog-log-slower-than 10000 (10 ms). Run SLOWLOG GET 128 to see recent slow commands. This catches the single most common cause of unexplained latency: someone ran KEYS * or SMEMBERS bigset in a background job and stalled the main loop for a full second.

Blocked clients

`blocked_clients` metric. Legitimate blocking (BLPOP consumers) will show up here. But if this number grows unexpectedly, clients are stuck waiting on Redis responses — often a sign of network problems or a slow command in progress.

Replication lag

`master_repl_offset` on primary − `slave_repl_offset` on each replica. Growing lag means a replica isn't keeping up. Some lag is normal; lag that stays bounded is usually tolerable, but lag that grows without bound is a real problem. If a replica is far enough behind, it will trigger a full sync on reconnect — which is expensive and can pause replication for other replicas.

Evictions

`evicted_keys` counter. Increasing = you're at your memory limit and Redis is dropping data. For a cache this is fine (expected steady state). For a session store or lock store, this is a warning that maxmemory-policy is aggressive and you may lose non-cache data.

Four failure patterns that commonly affect Redis deployments, with their symptoms, causes and fixes. They are representative patterns, not reports of specific incidents.

The slow-command stall

Symptom: ops/s drops to zero for 2 seconds, everything unblocks, life continues. Cause: someone ran KEYS * from a debug console, or an app did SMEMBERS on a set that grew to a million members. Fix: SLOWLOG will show the culprit. Rename KEYS and FLUSHDB in production; replace SMEMBERS with SSCAN; monitor P99 command latency.

Fork-induced swap death

Symptom: the whole box grinds to a halt during a BGSAVE. Cause: Redis fork() to snapshot; if writes are heavy, copy-on-write doubles memory faster than expected; kernel starts swapping; the process dies. Fix: leave enough headroom for copy-on-write growth during persistence, set vm.overcommit_memory=1, disable Transparent Huge Pages (transparent_hugepage=never) — THP can make fork() and copy-on-write much slower.

The thundering herd

Symptom: a hot key expires; a thousand app servers all try to regenerate it at the same time; the database gets slammed; latency across the whole system spikes. Fix: jittered TTLs (ttl + random(0, 60s)), single-flight fetch coordination (one app server does the work, the rest wait on a Redis lock), and stale-while-revalidate patterns — serve the stale value while one worker refreshes.

Silent data loss on failover

Symptom: a payment was processed but the record disappeared after a failover. Cause: async replication — the primary crashed before the replica caught up. Sentinel promoted the replica, unaware of the last few writes. Fix: use WAIT n 5000 for financial or state-critical operations, or push idempotency guards to the target system (Postgres has INSERT ON CONFLICT, use it).

The tools you'll actually reach for when Redis misbehaves.

MONITOR (use sparingly)

MONITOR streams every command being executed. Useful for a few seconds to see what's actually happening. Don't leave it running — it drops your instance throughput by ~50% because it duplicates every command to the monitor client.

SLOWLOG

SLOWLOG GET 128 returns the last 128 slow commands with timing and full argument list. This is the first tool to reach for on latency incidents. Reset with SLOWLOG RESET after triaging.

LATENCY monitor

CONFIG SET latency-monitor-threshold 100 to enable, then LATENCY LATEST to see the last big latency spike per source: fork, expire-cycle, command, AOF-fsync. This is how you distinguish 'a slow command' from 'the OS just paused us for a fork'.

MEMORY commands

MEMORY USAGE key returns the size of a value. MEMORY STATS gives a big breakdown of where memory is going. MEMORY DOCTOR runs heuristics and returns human-readable warnings. Use these when a Redis instance is unexpectedly bigger than it should be.

DEBUG SLEEP + DEBUG SEGFAULT

For testing your app's failure handling in staging. Never enable these in production without renaming. DEBUG SEGFAULT intentionally crashes the server so you can verify Sentinel failover actually works before you're relying on it in an incident.

The habits that separate a Redis you love from a Redis you rebuild every quarter.