Redis Explained for Backend Developers (From Cache to Core Infrastructure)

There are only two hard things in Computer Science: cache invalidation and naming things. - Phil Karlton

Almost every backend eventually hits the same wall: the database that was fast at a thousand requests per second falls over at fifty thousand. The queries have not changed. The indexes are fine. What changed is that reading from disk, joining tables, and re-computing the same answer for every caller is simply the wrong shape of work at that volume. Redis exists for exactly that mismatch - an in-memory data store that answers in microseconds and treats data structures, not tables, as its primitive.

But Redis is routinely misunderstood as "a cache you put in front of Postgres." That framing sells it short and, worse, leads teams into subtle bugs: caches that go stale, locks that release someone else's lock, queues that lose jobs on restart. Redis is a data structure server with durability options, replication, clustering, and atomic scripting. Used deliberately, it becomes core infrastructure - caching, session storage, rate limiting, queues, leaderboards, locks, and pub/sub - and each of those uses has correctness rules that are easy to get wrong.

Key Takeaway

• Redis is a data structure server, not just a key-value cache - choose the right structure (String, Hash, List, Set, Sorted Set, Stream) and most problems collapse into one or two commands.
• Command execution is effectively single-threaded, so every command is atomic - and a single slow command (KEYS, a big SORT) blocks every other client.
• Always set a TTL and an eviction policy. A cache without expiry is a memory leak that eventually becomes an outage.
• Pick the caching pattern deliberately - cache-aside, write-through, or write-behind - and understand exactly which one can serve stale data and when.
• Persistence is a spectrum: RDB snapshots, AOF, or both. Redis is not a system of record unless you have consciously configured it to be one.
• Use pipelining and Lua scripts to eliminate round trips and make multi-step operations atomic; never implement read-modify-write across two separate calls.
• Distributed locks, rate limits, and queues in Redis are correct only with the right primitives - fencing tokens, unique lock values, and Streams with consumer groups instead of naive LPUSH/RPOP.

Index

1. Introduction
2. Understanding the Redis Data Model
3. Caching Strategies & Patterns
4. Persistence, Memory & Eviction
5. Redis Beyond Caching
6. Operations, Scaling & Resilience
7. Stats & Interesting Facts
8. FAQ
9. Conclusion

1. Introduction

Redis - REmote DIctionary Server - was released in 2009 by Salvatore Sanfilippo, who built it because an analytics product he was running could not keep up with a traditional database. That origin still explains the design. Redis keeps the entire dataset in RAM, executes commands one at a time on a single thread, and exposes purpose-built data structures instead of a query language. There is no planner, no join, no schema. You reach for the structure that matches your access pattern and the operation is O(1) or O(log N) by construction.

That simplicity is the whole point. When a backend developer says "Redis is fast," what they usually mean is "Redis is in memory." That is only half of it. Redis is fast because the data structure already is the answer: a sorted set already holds the leaderboard in rank order, a hash already holds the session, a stream already holds the durable log. Nothing needs to be recomputed. The remaining cost is one network round trip - which is why the difference between a well-written and a badly-written Redis integration is almost never Redis itself, but how many times you talk to it.

The failure modes follow from the same design. Memory is finite, so eviction matters. There is one thread, so a single O(N) command stalls everyone. Persistence is optional, so a restart can lose data you assumed was safe. Replication is asynchronous, so a failover can lose recent writes. None of these are defects - they are trade-offs Redis makes explicitly in exchange for its latency. This article walks through the data model, caching patterns, persistence and memory behaviour, the non-cache use cases, and the operational concerns - with concrete, production-shaped code you can adapt.

2. Understanding the Redis Data Model

Before writing a single command, anchor your mental model. Redis is not a table store with a SELECT you cannot use. It is a collection of named data structures living in one flat keyspace. Choosing the right structure is most of the design work; once it is chosen, the commands are usually obvious. The structures fall naturally into three families.

2.1 The Core Structures: String, Hash, List

The String is the primitive - a byte blob up to 512 MB, holding anything from a serialized JSON object to a counter. INCR makes it an atomic counter; SET key val EX 60 NX makes it a lock or a one-shot flag. The Hash is a map of fields to values under one key - the correct structure for an object whose fields you update or read individually, such as a session or a user profile, because it avoids deserializing and rewriting the whole blob to touch one field. The List is a linked list with O(1) push and pop at both ends, useful for simple queues, capped activity feeds (LPUSH + LTRIM), and stacks. Reach for a Hash before a JSON String whenever fields are accessed independently.

// Hash for a session: read or update one field without touching the rest
  await redis.hset(`session:${sid}`, {
  userId: user.id,
  role: user.role,
  lastSeen: nowMs, // nowMs passed in - keep clocks explicit
});
await redis.expire(`session:${sid}`, 1800); // 30 min sliding TTL
// Later: touch only lastSeen - no read-modify-write of a JSON blob
await redis.hset(`session:${sid}`, 'lastSeen', nowMs);
const role = await redis.hget(`session:${sid}`, 'role');

2.2 Sets, Sorted Sets & Streams

A Set is an unordered collection of unique members with O(1) membership checks and native intersection, union, and difference - ideal for tags, unique visitors, or "which of these users are in this cohort." A Sorted Set (ZSET) adds a floating-point score per member and keeps the set ordered by that score. It is the single most underused structure in Redis: leaderboards, priority queues, sliding-window rate limiters, time-ordered indexes, and delayed-job schedulers are all sorted sets where the score is a rank, a priority, or a timestamp. A Stream is an append-only log with consumer groups and per-message acknowledgement - what you want for a real job queue, because unlike a List it survives a consumer crashing mid-job. Rounding out the set are Bitmaps and HyperLogLog, which answer "did user N do X today?" and "roughly how many unique users?" in a few hundred bytes.

// Sorted set: a leaderboard, ranked by score, in two commands
  await redis.zincrby('leaderboard:weekly', points, userId);
  // Top 10, highest first, with scores
   const top = await redis.zrevrange('leaderboard:weekly', 0, 9,   'WITHSCORES');
  // This user's rank - O(log N), no scan, no sort
  const rank = await redis.zrevrank('leaderboard:weekly', userId);

2.3 Atomicity, Pipelining & Lua
Redis executes commands on a single thread, so every individual command is atomic - no locking required, and no other client can observe a half-applied INCR. That guarantee stops at the command boundary. A GET followed by a SET is two commands, and another client can interleave between them - the classic lost-update race. When multiple steps must be atomic, use a Lua script (EVAL), which Redis runs to completion as one unit. Separately, and for a different reason, use pipelining to batch many independent commands into one round trip: pipelining is a latency optimisation, not an atomicity one. A hundred sequential GETs over a 1 ms link cost 100 ms; the same hundred in a pipeline cost roughly 1 ms.

// Lua: check-and-decrement inventory atomically. Two commands, one     unit.
   const RESERVE = `
   local stock = tonumber(redis.call('GET', KEYS[1]) or '0')
   if stock < tonumber(ARGV[1]) then return -1 end
   return redis.call('DECRBY', KEYS[1], ARGV[1])
   `;
   const remaining = await redis.eval(RESERVE, 1, `stock:${sku}`, qty);
   if (remaining === -1) throw new OutOfStockError(sku);
   // Pipeline: 3 round trips collapse into 1 (independent, NOT atomic)
  const [profile, unread, flags] = await redis.pipeline()
 .hgetall(`user:${id}`).scard(`unread:${id}`).smembers(`flags:${id}`)
 .exec().then(r => r.map(([err, val]) => val));

3. Caching Strategies & Patterns

Caching is where most teams meet Redis, and it is deceptively subtle. A cache is a second copy of the truth, and every caching bug is ultimately a question of what happens when the two copies disagree. Choose the pattern consciously, because each one has a different answer.

3.1 Cache-Aside, Write-Through & Write-Behind

Cache-aside (lazy loading) is the default and the one you should reach for first: the application checks Redis, and on a miss it reads the database, populates the cache, and returns. It is simple, resilient - a Redis outage degrades to slow, not broken - and only ever caches data someone actually asked for. Its weakness is that the first request after every miss pays full latency, and the cache can go stale if the database is written by anything that does not invalidate.

Write-through writes to the cache and the database synchronously on every write, keeping them consistent at the cost of write latency and of caching data that may never be read. Write-behind (write-back) acknowledges the write after only the cache write and flushes to the database asynchronously - very fast, and the only pattern here that can lose acknowledged data if Redis dies before the flush. Use it only where that loss is acceptable, such as metrics or view counters.
For invalidation, prefer deleting the key over updating it. Updating the cache on write reintroduces the race that two concurrent writers can apply their cache writes in the opposite order from their database writes; deleting simply forces the next reader to reload the truth.

// Cache-aside with a jittered TTL - the workhorse pattern
 async function getUser(id) {
  const key = `user:${id}`;
  const hit = await redis.get(key);
  if (hit) return JSON.parse(hit);
  const user = await db.users.findById(id);
  if (!user) return null;
  // Jitter prevents a whole cohort of keys expiring on the same second
  const ttl = 300 + Math.floor(jitterSeed % 60);
  await redis.set(key, JSON.stringify(user), 'EX', ttl);
  return user;
  }
  // On write: delete, never update. The next read repopulates from truth.
  async function updateUser(id, patch) {
  const user = await db.users.update(id, patch);
  await redis.del(`user:${id}`);
 return user;
}

3.2 TTLs, Stampedes & the Three Classic Cache Failures

Every key in a cache should have a TTL. Without one you are not caching, you are storing - and you will discover this when the instance hits maxmemory in production. Beyond that, three named failures account for most cache-related outages.

Cache penetration is repeated requests for a key that does not exist anywhere, so every request falls through to the database. Defend by caching the negative result with a short TTL, or with a Bloom filter. Cache avalanche (or stampede) is a large set of keys expiring simultaneously - typically because they were all written at the same time with the same TTL - sending a thundering herd at the database.
Defend by adding random jitter to every TTL. Hotspot invalidation is one extremely popular key expiring, so thousands of concurrent requests miss at once and all recompute the same value. Defend by having exactly one request rebuild the value while the others wait or serve slightly stale data - a mutex, implemented with SET NX.

// Stampede protection: exactly one rebuilder per key
async function getWithLock(key, rebuild, ttl) {
 const hit = await redis.get(key);
 if (hit !== null) return JSON.parse(hit);

 // NX = only if absent. EX = self-healing if the rebuilder crashes.
 const gotLock = await redis.set(`lock:${key}`, requestId, 'EX', 10, 'NX');
 if (!gotLock) {
   await sleep(50);              // someone else is rebuilding
   return getWithLock(key, rebuild, ttl);
 }
 try {
   const fresh = await rebuild();
   // Cache the miss too - defeats cache penetration
   await redis.set(key, JSON.stringify(fresh), 'EX', fresh ? ttl : 30);
   return fresh;
 } finally {
   await redis.del(`lock:${key}`);
 }
}

3.3 Key Design & Naming

The keyspace is flat and global, so naming is your only schema. Adopt a colon-delimited, hierarchical convention - app:entity:id:field, for example shop:cart:8f21:items - and apply it everywhere. Include a version segment (v2:user:42) so a schema change can be rolled out by writing to new keys rather than by a risky mass invalidation. Keep keys short but readable: every key name lives in RAM. Never run KEYS * against production - it is O(N) over the entire keyspace on the single command thread, and it will stall the server. Use SCAN, which is cursor-based and incremental.

4. Persistence, Memory & Eviction

Redis lives in RAM, and RAM is both volatile and finite. Those two facts generate the two questions every Redis deployment must answer explicitly: what happens on restart, and what happens when memory runs out. Answering them by default is how teams end up surprised.

4.1 RDB, AOF & What "Durable" Really Means

Redis offers two persistence mechanisms. RDB takes point-in-time binary snapshots on a schedule - compact, fast to load, and cheap at runtime, but a crash loses everything written since the last snapshot. AOF (Append Only File) logs every write command and replays it on startup. With appendfsync everysec - the sane default - you lose at most one second of writes; with always you lose nothing but pay an fsync per write. Running both is the common production choice: AOF for recovery fidelity, RDB for fast restarts and backups.

Be precise about what this buys you. Even with AOF, replication to a replica is asynchronous, so a primary failover can lose the writes that had not yet reached the replica. Redis is a superb cache and a good queue; it is a system of record only if you have configured it as one and accepted the remaining window. If losing a write is unacceptable, the write belongs in your database first.

# redis.conf - both mechanisms, the common production posture
save 900 1                      # RDB: snapshot if ≥1 key changed in 15 min
save 300 10
appendonly yes                  # AOF on
appendfsync everysec            # ≤1s loss window; 'always' = slowest, safest
auto-aof-rewrite-percentage 100 # compact the log when it doubles

4.2 maxmemory & Eviction Policies

Always set maxmemory. If you do not, Redis will consume until the OS out-of-memory killer terminates it - the worst possible failure mode, because it is abrupt and total. Once the limit is set, the eviction policy decides what happens when it is reached. For a pure cache, use allkeys-lru (evict least-recently-used) or allkeys-lfu (least-frequently-used, better when a small hot set dominates). Use volatile-* variants when the same instance also holds keys that must never be evicted - though mixing cache and non-cache data in one instance is usually a mistake. The default, noeviction, makes writes fail with an error once full: correct for a queue or a session store, catastrophic for a cache.

# A cache instance: bound the memory, evict the coldest keys
maxmemory 4gb
maxmemory-policy allkeys-lru

# A session/queue instance: never silently drop data - fail the write instead
maxmemory 2gb
maxmemory-policy noeviction

4.3 Memory Behaviour & Big Keys

Two memory characteristics catch people out. First, Redis expires keys lazily plus via a sampling background job - an expired key still occupies memory until it is touched or sampled, so "TTL passed" and "memory freed" are not the same instant. Second, a big key - a single Hash with a million fields, or a List with ten million entries - is dangerous out of proportion to its size, because deleting it, or any O(N) command against it, occupies the one command thread for the entire operation. Prefer UNLINK over DEL to free large keys in a background thread, shard big collections across several keys, and audit periodically with redis-cli --bigkeys and MEMORY USAGE.

Redis is a data structure server. It is not a database with data structures bolted on. - Salvatore Sanfilippo, creator of Redis

5. Redis Beyond Caching

Treating Redis purely as a cache leaves most of its value unused. The same data structures that make caching fast make a handful of otherwise-hard distributed problems almost trivial - provided you use the correct primitive rather than the first one that appears to work.

5.1 Rate Limiting, Locks & Counters

Rate limiting is a sorted set or a counter with a TTL: a fixed window is a single INCR on a key named for the current window, while a sliding window is a ZSET of timestamps trimmed by ZREMRANGEBYSCORE. Distributed locks are the sharpest edge in Redis. A lock must be acquired with SET key NX EX - the TTL so a crashed holder cannot deadlock the system, the unique value so that the release step can verify ownership. Releasing with a bare DEL is a real bug: if your lock expired and another process acquired it, you will delete their lock. Release must be a Lua compare-and-delete. Even then, understand the limit - a Redis lock protects against contention, not against a process that stalls past its TTL and resumes. For operations where a double execution would be unacceptable, pair the lock with a fencing token checked at the resource.

// Safe release: compare-and-delete, atomically. A bare DEL is a bug.
const UNLOCK = `
 if redis.call('GET', KEYS[1]) == ARGV[1] then
   return redis.call('DEL', KEYS[1])
 end
 return 0
`;
async function withLock(resource, token, ttlMs, fn) {
 const ok = await redis.set(`lock:${resource}`, token, 'PX', ttlMs, 'NX');
 if (!ok) throw new LockContendedError(resource);
 try { return await fn(); }
 finally { await redis.eval(UNLOCK, 1, `lock:${resource}`, token); }
}
// Fixed-window rate limit: two commands, one pipeline
const [count] = await redis.pipeline()
 .incr(`rl:${userId}:${windowId}`)
 .expire(`rl:${userId}:${windowId}`, 60)
 .exec().then(r => r.map(([e, v]) => v));
if (count > 100) throw new RateLimitedError();

5.2 Queues, Streams & Pub/Sub

These three look similar and are not interchangeable. Pub/Sub is fire-and-forget: a message is delivered to whoever is connected at that instant and is then gone forever. A subscriber that was restarting misses it. Use Pub/Sub for cache-invalidation fan-out or live notifications where loss is tolerable - never for jobs.

A List queue (LPUSH + BRPOP) is a genuine queue, but the job vanishes from Redis the moment a worker pops it. If that worker crashes mid-job, the job is lost with no record. Streams solve exactly this: an append-only log where consumer groups track per-message delivery and a message stays in a pending list until it is explicitly XACK-ed. A crashed consumer's messages can be reclaimed with XAUTOCLAIM and retried. For any job that matters, use a Stream - or a purpose-built queue library on top of one.

// Stream consumer group: at-least-once delivery with explicit ack
await redis.xgroup('CREATE', 'jobs', 'workers', '$', 'MKSTREAM')
          .catch(() => {});                    // BUSYGROUP = already exists

const msgs = await redis.xreadgroup(
 'GROUP', 'workers', workerId, 'COUNT', 10, 'BLOCK', 5000,
 'STREAMS', 'jobs', '>');                     // '>' = undelivered only

for (const [id, fields] of msgs?.[0]?.[1] ?? []) {
 await handle(fields);
 await redis.xack('jobs', 'workers', id);      // unacked ⇒ redelivered
}

// Reclaim messages stranded by a crashed worker
await redis.xautoclaim('jobs', 'workers', workerId, 60000, '0');

6. Operations, Scaling & Resilience

Redis is easy to run and easy to run badly. The failure modes are rarely gradual: latency is flat until it is not, and memory is fine until the instance dies. The controls below are what keep a Redis deployment healthy past launch day.

6.1 Replication, Sentinel & Cluster

Scale in the order the problem demands. Replication gives you read scaling and a warm standby: replicas asynchronously copy the primary, and reads may be slightly stale. Sentinel adds automatic failover by monitoring the primary and promoting a replica - availability, not more capacity. Cluster is the answer when the dataset or the write throughput exceeds one machine: the keyspace is partitioned across 16,384 hash slots distributed over the shards, and each shard owns a subset. Cluster mode brings a real constraint - a multi-key command only works if every key lives in the same slot - which you control with hash tags: user:{42}:profile and user:{42}:cart share the slot determined by 42. Do not adopt Cluster before you need it; a single well-provisioned primary with a replica handles more than most systems ever ask.

6.2 Latency, Slow Commands & Connection Handling

Because one thread executes every command, latency is a shared resource. Any O(N) command against a large key - KEYS, SMEMBERS on a huge set, HGETALL on a huge hash, FLUSHALL, an unbounded LRANGE - blocks every other client for its full duration. Replace them with their cursor-based equivalents (SCAN, HSCAN, SSCAN) and enable the slowlog. Equally, connection churn will dominate your latency budget long before Redis does: always use a connection pool, never open a client per request, and set explicit connect and command timeouts so a Redis blip degrades your service instead of hanging every request thread.

# Find what is actually blocking the thread
redis-cli CONFIG SET slowlog-log-slower-than 10000   # log commands > 10ms
redis-cli SLOWLOG GET 10
redis-cli --latency-history -i 5
redis-cli --bigkeys                                  # the usual culprits
# Iterate the keyspace safely - never KEYS * in production
redis-cli --scan --pattern 'session:*' | head

6.3 Security & Configuration

An unauthenticated Redis reachable from the internet is compromised within hours - it has been one of the most reliably exploited misconfigurations of the last decade. Bind Redis to a private interface, never 0.0.0.0. Require authentication and prefer Redis 6+ ACLs over a single shared requirepass, so each service gets its own user scoped to the commands and key patterns it needs. Enable TLS for traffic that crosses a trust boundary. Rename or disable the destructive administrative commands - FLUSHALL, CONFIG, DEBUG - and keep protected mode on. Finally, never store secrets, tokens, or unredacted PII in a cache you have not encrypted and access-controlled as carefully as your primary database.

# ACL: one user per service, least privilege over commands and keys
ACL SETUSER api-cache on >s3cr3t \
   ~cache:*             # only keys matching cache:* \
   +get +set +del +expire +scan   # only these commands
# redis.conf hardening
bind 10.0.1.5 -::1
protected-mode yes
rename-command FLUSHALL ""
rename-command CONFIG   ""

6.4 Monitoring & Capacity

Four signals tell you almost everything. Hit rate (keyspace_hits versus keyspace_misses) tells you whether the cache is earning its keep; a falling hit rate usually means TTLs are too short or the working set has outgrown memory. Evicted keys climbing means you are at maxmemory and silently shedding data. Memory fragmentation ratio far above 1.0 means the allocator is holding memory the dataset is not using. And blocked clients plus slowlog depth tell you the command thread is stalling. Alert on all four, and load-test with redis-benchmark against a realistic key distribution rather than the default uniform one - caches behave entirely differently under a skewed, real-world access pattern.

7. Stats & Interesting Facts

• Redis was created by Salvatore Sanfilippo and first released in 2009 - written in C, it remains one of the most widely deployed open-source infrastructure components in the world.Source: https://redis.io/about/
• DB-Engines has ranked Redis the most popular key-value store for over a decade running, consistently placing it in the overall top ten databases alongside Oracle, MySQL, and PostgreSQL.Source: https://db-engines.com/en/ranking/key-value+store
• Redis has appeared year after year among the most admired and most used databases in the Stack Overflow Developer Survey, which polls tens of thousands of professional developers annually.Source: https://survey.stackoverflow.co/2024/technology
• A Redis Cluster partitions the keyspace into exactly 16,384 hash slots. The number is not arbitrary - it keeps the cluster bus's slot bitmap small enough to gossip cheaply between nodes.Source: https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/
• A single Redis String value can hold up to 512 MB, and command execution is single-threaded by design - which is precisely why one O(N) command can stall every other client on the instance.Source: https://redis.io/docs/latest/develop/data-types/
• In March 2024 Redis changed its licence from BSD to a dual RSALv2/SSPL model, prompting the Linux Foundation to fork the last BSD version as Valkey. In May 2025 Redis 8 added AGPLv3 as an option - a licensing history worth knowing before you standardise on either. Source: https://redis.io/blog/agplv3/
• Publicly exposed, unauthenticated Redis instances have been a persistent target for cryptomining and ransomware campaigns for years - the reason protected-mode was made the default in Redis 3.2.Source: https://redis.io/docs/latest/operate/oss_and_stack/management/security/

8. FAQ

1. Is Redis just a cache, or can it be my primary database?
Ans: It can be a primary database, but only for data whose durability requirements you have consciously matched to its configuration. With AOF at appendsync always and synchronous WAIT-based confirmation, Redis is genuinely durable; with the defaults, a crash can lose the last second of writes and an asynchronous failover can lose more. Most teams get the best outcome by treating a relational database as the system of record and Redis as the fast, disposable layer in front of it.

2. Redis is single-threaded - isn't that a bottleneck?
Ans: Rarely, and for a counter-intuitive reason. Because operations are in-memory and O(1), a single thread routinely sustains six figures of operations per second; the bottleneck is almost always the network or your client's round trips, not Redis's CPU. Modern Redis also uses extra threads for I/O and for background deletes. The real risk of single-threading is not throughput but head-of-line blocking: one slow O(N) command stalls everyone, which is why big keys and KEYS * are so dangerous.

3. When should I use a Hash instead of storing JSON in a String?
Ans: Use a Hash whenever you read or write individual fields. A JSON String forces you to fetch the whole object, deserialize it, mutate one field, re-serialize, and write it back - which is both slower and a lost-update race between two concurrent writers. Use a String when the object is always read and written as a whole, or when you need to store a value your Hash cannot represent, such as a deeply nested document.

4. How do I keep my cache from serving stale data?
Ans: You cannot eliminate staleness; you bound it. Set a TTL that matches how stale the data may acceptably be, and invalidate on write by deleting the key rather than updating it - deletion forces the next reader to reload from the source of truth and avoids the race where two writers apply cache writes out of order. Ensure every path that writes the underlying data also invalidates, including background jobs and admin tools; a single un-invalidating writer defeats the whole scheme.

5. What is a cache stampede, and how do I prevent it?
Ans: A stampede happens when a popular key expires and every concurrent request misses at once, sending a thundering herd to the database to compute the same value. Prevent it two ways: add random jitter to every TTL so keys do not expire in lockstep, and use a mutex (SET NX with a short TTL) so exactly one request rebuilds the value while the rest wait briefly or serve the last known value.

6. Are Redis distributed locks safe?
Ans: Safe enough for coordination, not sufficient for correctness on their own. Always acquire with SET key NX PX and release with a Lua compare-and-delete, or you will eventually delete a lock another process now holds. Understand the residual risk: if your process pauses past the TTL - a long GC pause, a slow disk - the lock expires and two processes believe they hold it. For operations where double execution is unacceptable, make the operation idempotent or use a fencing token the resource itself validates.

7. Should I use a List or a Stream for a job queue?
Ans: A Stream, for anything that matters. A List queue removes the job the instant a worker pops it, so a worker crashing mid-job loses that job with no record. Streams keep the message in a per-consumer pending list until it is explicitly acknowledged with XACK, and stranded messages can be reclaimed and retried with XAUTOCLAIM. Lists remain fine for lossy work such as best-effort notifications.

8. What eviction policy should I choose?
Ans: It depends on what the instance holds. For a pure cache, use allkeys-lru, or allkeys-lfu when a small hot set dominates a long tail. For a session store or queue where silently dropping data would be a bug, use no eviction so writes fail loudly at the limit. What you must not do is leave maxmemory unset - Redis will then grow until the operating system kills the process.

9. When do I actually need Redis Cluster?
Ans: Later than you think. Reach for Cluster only when your dataset genuinely exceeds the RAM of one machine, or your write throughput exceeds one primary - read load is solved far more cheaply with replicas. Cluster imposes a real cost: multi-key operations and transactions require all keys in the same hash slot, which forces hash tags into your key design. A single well-provisioned primary with a replica and Sentinel serves the overwhelming majority of production systems.

Memory is fast and finite; disk is slow and forgiving. Every caching decision is a trade between the two. - Backend folk wisdom

9. Conclusion

Redis rewards developers who understand what it actually is. Not a magic accelerator to be sprinkled in front of a slow query, but a data structure server whose speed comes from having already arranged the data in the shape your answer requires. Every meaningful decision in a Redis integration follows from a handful of properties, and every classic Redis bug follows from ignoring one of them:

• The data model is the design. Choosing a Sorted Set over a List, or a Hash over a JSON String, usually turns a complicated problem into two commands.
• One thread, one command at a time. That gives you free atomicity per command - and makes a single O(N) command against a big key an outage for every other client.
• Memory is bounded and volatile. Set maxmemory, set an eviction policy, set a TTL on every cached key, and decide consciously what a restart is allowed to lose.
• Caching is a consistency problem, not a performance one. Pick a pattern, invalidate by deleting, jitter your TTLs, and guard hot keys against stampedes.
• Multi-step means Lua; many-step means pipeline. Never read-modify-write across two round trips, and never pay a round trip you could have batched away.
• The non-cache uses have sharp edges. Locks need unique tokens and compare-and-delete releases; job queues need Streams and acknowledgements; Pub/Sub loses messages by design.

Used carelessly, Redis becomes a second, stale, unmonitored copy of your database that fails at the worst moment. Used deliberately, it disappears - requests get faster, the database gets quieter, and whole categories of distributed coordination reduce to a single command. That invisibility is the mark of a Redis layer built by someone who understood the trade-offs rather than one who simply added a cache.

About the Author:Abodh is a PHP and Laravel Developer at AddWeb Solution, skilled in MySQL, REST APIs, JavaScript, Git, and Docker for building robust web applications.