DatabasesBackend Engineer to Staff Systems Architect17 min read·Updated for Redis 7.4, Cluster v2 & Redlock Best Practices

Redis System Design Guide: Caching, Eviction, Persistence & Distributed Locks

From Data Structure Internals to Redlock, Redis Cluster & Production-Grade Caching Architecture

Priya Nataraj

Staff Data Engineer & Distributed Caching Specialist

11+ Years Building High-Throughput Caching & Data Platforms

Prep Timeline

3 to 5 Weeks

Format

System Design, Backend Deep-Dive, Database Internals

Conversion

+74% System Design Round Confidence

Redis System Design Guide: Caching, Eviction, Persistence & Distributed Locks

Executive Summary & Key Takeaways

What You Must Master to Clear This Track

Know the exact complexity and internal encoding of Strings, Hashes, Sorted Sets, and Streams so you can justify data structure choices under load.
Distinguish cache-aside, write-through, and write-behind by who owns writing to the cache and what staleness or data-loss window each accepts.
Explain eviction policy trade-offs (LRU vs LFU vs TTL-based) and why the default noeviction policy silently rejects writes once maxmemory is hit.
Articulate the RDB vs AOF durability trade-off: RDB is fast to restore but loses minutes of data, AOF with everysec loses at most one second but is slower to replay.
Understand that Redis Cluster shards via 16384 hash slots (not consistent hashing) and that Redlock trades perfect safety for pragmatic multi-instance liveness.

Structured Preparation Timeline

Step-by-Step Study Plan

Follow this sequential roadmap designed to take you from core foundations to advanced architecture and mock interviews.

Phase 1 (Week 1)

Data Structure Selection & Complexity Analysis

Core Data Structures & In-Memory Fundamentals

Strings, Hashes, Lists, Sets, Sorted Sets, and Streams, including their internal encodings (listpack/ziplist, skip list + hash table) and when to reach for each.

Key Milestones

•Explain why ZSET uses a skip list plus hash table to give O(log N) ZADD/ZRANGE and O(1) ZSCORE lookups simultaneously.
•Model a leaderboard, a rate limiter, and a session store using the right primitive for each.
•Understand Streams (XADD, consumer groups, XACK/XPENDING) as a lightweight Kafka alternative for at-least-once delivery.

Recommended Actions

•Run MEMORY USAGE and OBJECT ENCODING on real keys to see listpack vs hashtable/skiplist transitions.
•Practice explaining Big-O for at least 6 commands per data type out loud.

Phase 2 (Week 2)

Cache Consistency Strategies & Durability Trade-offs

Caching Patterns, Eviction & Persistence

Cache-aside, write-through, and write-behind patterns; LRU/LFU/TTL eviction policies under memory pressure; RDB snapshotting vs AOF durability.

Key Milestones

•Draw the full cache-aside read/write path including cache stampede protection.
•Compare maxmemory-policy options and pick the correct one for a session cache vs a computed-results cache.
•Explain fork() + copy-on-write for BGSAVE and appendfsync always/everysec/no trade-offs for AOF.

Recommended Actions

•Configure a local Redis instance with maxmemory and allkeys-lfu, then observe eviction under synthetic load.
•Enable AOF with appendfsync everysec and inspect the rewrite log to understand compaction.

Phase 3 (Weeks 3-4)

High Availability, Sharding & Redlock

Replication, Cluster Topology & Distributed Coordination

Sentinel-based failover, Redis Cluster's 16384 hash slots, cross-slot operation limitations, Redlock distributed locking, and Redis-backed rate limiting.

Key Milestones

•Trace a Sentinel quorum failover from primary failure detection to replica promotion.
•Explain hash slot routing, MOVED/ASK redirection, and resharding in Redis Cluster.
•Implement a Redlock-style lock across 3-5 independent Redis instances with a majority quorum and safe release via Lua.

Recommended Actions

•Practice deriving RPS, memory footprint, and shard count for a 50M-user session store on a whiteboard.
•Discuss known Redlock criticisms (clock drift, GC pauses) and how fencing tokens mitigate them.

Deep-Dive Architecture & Concepts

1. Redis Core Data Structures & Time Complexity

Redis is fundamentally an in-memory data structure server, not just a key-value cache. Picking the right structure for the access pattern is what separates a naive cache from a well-designed one.

Strings

O(1) GET/SET/INCR. Backed by Simple Dynamic Strings (SDS); small integers use a shared object pool. Ideal for counters, feature flags, and serialized cache blobs (JSON/Protobuf).

Hashes

O(1) HGET/HSET/HDEL. Encoded as a compact listpack for small field counts, converting to a full hash table past hash-max-listpack-entries. Ideal for storing an object's fields (a user profile) without a full JSON deserialize.

Sorted Sets (ZSET)

O(log N) ZADD/ZRANGE/ZRANK via a skip list combined with a hash table for O(1) score lookups. Ideal for leaderboards, priority queues, and sliding-window rate limiters keyed by timestamp score.

Streams

O(1) amortized XADD append-only log with consumer groups, XACK, and XPENDING for at-least-once delivery. Ideal for event sourcing, activity feeds, and lightweight pub/sub replacements that need replay and backpressure.

Lists & Sets

Lists (O(1) LPUSH/RPUSH, O(N) LINDEX) work well as bounded queues; Sets (O(1) SADD/SISMEMBER) are ideal for deduplication, tagging, and fast membership checks like unique-visitor tracking.

Interviewer Insights & Pro Tips

Run OBJECT ENCODING <key> in interviews-style discussion to show you understand that small collections silently use compact encodings (listpack) before promoting to hash tables or skip lists.
Prefer Hashes over storing one String key per object field — it collapses N keys into 1, cutting memory overhead from per-key bookkeeping.

Red Flags & Common Pitfalls

Using a single giant String (a multi-MB JSON blob) as a hot key — Redis is single-threaded per command, so large value serialization/deserialization blocks the event loop.
Choosing a List for a queue that needs random access or dedup — Lists have O(N) LINDEX/LREM, which quietly becomes a bottleneck as it grows.

Deep-Dive Architecture & Concepts

2. Caching Patterns: Cache-Aside, Write-Through, Write-Behind & Eviction

The caching pattern you choose determines who is responsible for cache population, how stale reads can get, and what happens to writes during a cache outage.

Cache-Aside (Lazy Loading)

Application code checks the cache first; on a miss it reads the DB and populates the cache with a TTL. Simplest and most common pattern — cache only holds what's actually requested, but the first request after a miss always pays the full DB latency.

Write-Through

Every write goes through the cache, which synchronously writes to the DB before acknowledging. Guarantees cache and DB never diverge, at the cost of added write latency on every request.

Write-Behind (Write-Back)

Writes land in the cache and are asynchronously flushed to the DB in batches. Lowest write latency and highest throughput, but risks data loss if the cache crashes before the flush completes.

Eviction Policies Under Memory Pressure

allkeys-lru/allkeys-lfu approximate true LRU/LFU using random sampling (not a full linked list) for O(1)-ish eviction; volatile-ttl evicts keys closest to expiry first; noeviction (the default) rejects writes outright once maxmemory is reached.

Cache-Aside Read/Write Lifecycle

The request path an application follows on a cache miss versus a subsequent cache hit.

Client Read Request

App server receives a request for a product and computes the cache key (e.g. product:1042).

Cache Lookup (GET)

Redis is queried first; on a hit, the serialized value is returned immediately with sub-millisecond latency.

Cache Miss -> DB Query

On a miss, the app queries the primary database (or a read replica) for the authoritative record.

Populate Cache with TTL

The result is written back to Redis with an expiry (plus jitter) so future reads hit the cache and stale data self-heals.

Return to Client

The response is returned to the caller; subsequent requests for the same key are served entirely from memory until TTL expiry or invalidation.

Cache-Aside Read Path with Stampede Protection (TTL Jitter + Mutex)

typescript

import { redis } from "./redisClient";
  import { db } from "./db";
  
  const TTL_SECONDS = 300;
  const JITTER_SECONDS = 30;
  
  async function getProduct(productId: string) {
    const cacheKey = `product:${productId}`;
    const cached = await redis.get(cacheKey);
    if (cached) return JSON.parse(cached);
  
    // Prevent cache stampede: only one caller rebuilds a hot key
    const lockKey = `lock:${cacheKey}`;
    const acquiredLock = await redis.set(lockKey, "1", "NX", "EX", 5);
  
    if (!acquiredLock) {
      // Another request is already rebuilding; brief backoff then retry read
      await new Promise((r) => setTimeout(r, 50));
      return getProduct(productId);
    }
  
    try {
      const product = await db.products.findById(productId);
      if (product) {
        const ttl = TTL_SECONDS + Math.floor(Math.random() * JITTER_SECONDS);
        await redis.set(cacheKey, JSON.stringify(product), "EX", ttl);
      }
      return product;
    } finally {
      await redis.del(lockKey);
    }
  }

Why it matters: Adding random jitter to the TTL prevents many keys from expiring at the exact same millisecond (thundering herd), and the short-lived NX lock ensures only one request rebuilds a given hot key while others wait instead of all hammering the DB simultaneously.

Interviewer Insights & Pro Tips

For write-heavy workloads with tolerable data-loss windows (e.g. view counters, analytics), write-behind batching to the DB can cut write amplification by an order of magnitude.
Always set an explicit maxmemory-policy — leaving the default noeviction on a pure cache instance means Redis starts returning OOM errors on writes instead of evicting old data.

Red Flags & Common Pitfalls

Forgetting to invalidate or update the cache key on a write path in cache-aside, leaving stale data served until TTL expiry.
Using write-through for a cold, rarely-read dataset — you pay synchronous write cost for data that may never be read from cache again.

Deep-Dive Architecture & Concepts

3. Persistence: RDB Snapshots vs AOF & Durability Trade-offs

Redis is in-memory first, but production deployments almost always need a durability story for restarts and crash recovery — the choice between RDB and AOF is a direct trade-off between recovery speed and data-loss window.

RDB (Point-in-Time Snapshots)

SAVE/BGSAVE forks the process and uses copy-on-write to write a compact binary snapshot without blocking the main event loop. Fast to load on restart, but any writes since the last snapshot (seconds to minutes) are lost on a crash.

AOF (Append-Only File)

Logs every write command; appendfsync controls durability: always (fsync every write, safest, slowest), everysec (fsync once per second, default, loses at most ~1s), no (OS-controlled, fastest, least safe).

AOF Rewrite / Compaction

Over time the AOF log grows unbounded; BGREWRITEAOF forks and rewrites it as the minimal set of commands needed to reconstruct current state, similar in mechanism to RDB's copy-on-write fork.

Hybrid Persistence (RDB + AOF)

Redis 4+ can prefix the AOF file with an RDB-formatted snapshot on rewrite, combining RDB's fast restart with AOF's minimal data-loss window — the recommended default for most production deployments.

Interviewer Insights & Pro Tips

For a pure cache tier where the DB is the source of truth, disable persistence entirely (save "", appendonly no) — losing the cache is cheap, and you avoid fork-related latency spikes on a large dataset.
For Redis used as a system of record (queues, session stores without a backing DB), enable hybrid persistence with appendfsync everysec as the default balance.

Red Flags & Common Pitfalls

Running BGSAVE on a host with insufficient free memory — copy-on-write can double memory usage under heavy write load during the fork, triggering OOM kills.
Assuming appendfsync always is 'safe' without measuring latency impact — it fsyncs on every single write and can drop throughput by 10x or more on spinning or network-attached disks.

Deep-Dive Architecture & Concepts

4. Replication, High Availability, Distributed Locks & Rate Limiting

Beyond a single node, production Redis needs a failover story (Sentinel), a sharding story (Cluster), and often distributed coordination primitives (Redlock) layered on top.

Asynchronous Replication

Primary replicates to replicas asynchronously by default; replicas can serve reads but may lag behind, so a failover can lose the last few unacknowledged writes (an AP-leaning trade-off, not full CP consistency).

Sentinel: Automatic Failover

A quorum of independent Sentinel processes monitors primaries, agrees via majority vote that a primary is down, and promotes the most up-to-date replica — client libraries discover the new primary via Sentinel's pub/sub notifications.

Redis Cluster: Hash Slot Sharding

Data is partitioned across exactly 16384 hash slots (CRC16(key) mod 16384), each owned by one primary node; multi-key operations across slots fail with a CROSSSLOT error unless keys share a hash tag ({user123}:profile).

Redlock: Distributed Mutual Exclusion

Acquire a lock with the same key/value across N independent Redis masters (typically 5); the lock is considered held only if a majority (N/2+1) acknowledge within a bounded time budget, and release deletes the key only if the value still matches (via a Lua script) to avoid deleting someone else's lock.

Rate Limiting with Redis

Token bucket via INCR + EXPIRE for fixed windows, or a sliding-window log using a ZSET keyed by timestamp (ZADD + ZREMRANGEBYSCORE to evict old entries + ZCARD to count) for smoother, burst-resistant limiting.

Redis Cluster Hash Slot Routing

How a client request is routed to the correct shard using CRC16 hash slots, including redirection on resharding.

Client Computes Slot

Client (or a slot-aware library) computes CRC16(key) mod 16384 to determine the target hash slot.

Route to Owning Node

Request is sent directly to the primary node that owns that slot range, based on a locally cached cluster topology.

MOVED Redirection

If the slot has migrated to another node (permanent reassignment), that node returns a MOVED error with the correct address; the client updates its slot cache and retries.

ASK Redirection (Mid-Resharding)

If a slot is actively being migrated, the old node returns an ASK error for keys already moved, directing the client to retry against the new node with an ASKING flag.

Response Returned

Once routed correctly, the owning node executes the command and returns the result directly to the client.

Simplified Redlock: Acquire & Safe Release Across N Redis Masters

typescript

import { randomUUID } from "crypto";
  import type Redis from "ioredis";
  
  const LOCK_TTL_MS = 10_000;
  const DRIFT_FACTOR = 0.01;
  
  // Lua script: only delete the key if the value still matches our token
  const RELEASE_SCRIPT = `
  if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
  else
    return 0
  end
  `;
  
  async function acquireLock(clients: Redis[], resource: string) {
    const token = randomUUID();
    const quorum = Math.floor(clients.length / 2) + 1;
    const start = Date.now();
  
    let acquiredCount = 0;
    await Promise.all(
      clients.map(async (client) => {
        const ok = await client.set(resource, token, "PX", LOCK_TTL_MS, "NX");
        if (ok === "OK") acquiredCount++;
      })
    );
  
    const elapsed = Date.now() - start;
    const validityMs = LOCK_TTL_MS - elapsed - Math.round(LOCK_TTL_MS * DRIFT_FACTOR);
  
    if (acquiredCount >= quorum && validityMs > 0) {
      return { token, validityMs };
    }
  
    // Failed to reach quorum: release on every node before giving up
    await releaseLock(clients, resource, token);
    return null;
  }
  
  async function releaseLock(clients: Redis[], resource: string, token: string) {
    await Promise.all(clients.map((client) => client.eval(RELEASE_SCRIPT, 1, resource, token)));
  }

Why it matters: Requiring a majority quorum (not all N nodes) keeps the lock available if a minority of instances are down, while the compare-and-delete Lua script on release prevents a slow client from deleting a lock it no longer owns after its TTL expired and someone else acquired it.

Interviewer Insights & Pro Tips

Use hash tags like {order:5001}:items and {order:5001}:status to force related keys into the same slot so multi-key operations (MGET, transactions) don't hit CROSSSLOT errors.
For most single-datacenter use cases, a well-tuned Sentinel setup with WAIT for replica acknowledgment is simpler and sufficient — reach for Redlock only when you need cross-instance mutual exclusion, not just single-primary locking.

Red Flags & Common Pitfalls

Treating Redlock as a perfect distributed consensus mechanism — under process pauses (GC, VM stop-the-world) or clock jumps, two clients can briefly believe they both hold the lock; use fencing tokens on the protected resource for true safety.
Running Redis Cluster with only 3 nodes and no replicas — losing a single primary before its slot range is recovered causes cluster-wide unavailability for that slot range.

Real-World Example

Eliminating Overselling and Database Overload During Flash Sales at a Mid-Size E-Commerce Platform

A mid-size e-commerce company's flagship flash-sale events routinely overwhelmed their primary MySQL read replicas, causing checkout latency spikes above 4 seconds and, worse, occasional overselling of limited-inventory SKUs when multiple app instances decremented stock concurrently without coordination.

1Introduced a cache-aside layer in front of product catalog reads using Redis, with a 30-second TTL plus randomized jitter to prevent synchronized mass expiry across thousands of SKU keys.
2Added a short-lived per-key mutex (SET NX PX) so that on a cache miss for a suddenly hot product, only one request rebuilt the cache entry while concurrent requests waited briefly and retried, eliminating stampede-driven DB spikes.
3Replaced ad-hoc application-level inventory checks with a Redlock-based distributed lock across a 5-node Redis quorum to serialize stock-decrement operations per SKU across all app server instances.
4Migrated session storage from sticky in-memory sessions to a Redis Cluster deployment sharded via hash slots, enabling horizontal scaling of app servers without session-affinity constraints.
5Configured Sentinel-based automatic failover for the lock and session Redis tiers, with WAIT-based replica acknowledgment on critical inventory-lock writes to reduce the risk of losing a lock state during a primary failover mid-sale.

Outcome: Database read load during flash sales dropped by roughly 92%, checkout latency stabilized under 300ms at peak, and overselling incidents dropped to zero across the following three flash-sale events.

Real-World Interview Questions

Mistakes That Sink Otherwise Strong Candidates

Leaving maxmemory-policy at its default (noeviction) on an instance used purely as a cache.

Why it happens: Teams provision Redis for caching without revisiting the default configuration, assuming Redis will 'just evict old stuff' automatically once memory fills up.

The fix: Explicitly set an eviction policy like allkeys-lru or allkeys-lfu for pure cache instances, reserving noeviction only for Redis deployments acting as a system of record.

Running the KEYS * command (or unbounded pattern scans) against a production instance.

Why it happens: KEYS is the first command developers learn for inspecting a keyspace, and it works fine on a small local dataset, masking its O(N) blocking behavior until the dataset grows in production.

The fix: Use SCAN with a cursor for any production keyspace iteration — it processes the keyspace incrementally without blocking other clients.

Treating Redlock as an unconditionally safe distributed lock for any critical section.

Why it happens: Redlock's design looks like a rigorous consensus algorithm, so teams assume it eliminates all race conditions without accounting for clock drift or process pauses.

The fix: Use Redlock for reducing the probability of concurrent access in practice, and add fencing tokens on the protected resource itself whenever correctness truly cannot tolerate a rare double-acquisition.

Not adding jitter to cache TTLs, causing thousands of keys to expire at the same instant.

Why it happens: A batch cache-warming job or bulk cache population at startup writes many keys with the exact same TTL value, so they all expire simultaneously later.

The fix: Add a randomized offset (e.g. +/- 10-15% of the base TTL) to every cache write so expirations spread out over time instead of clustering.

Storing large multi-megabyte blobs as single String values on a hot key.

Why it happens: It's the path of least resistance to just JSON.stringify() an entire nested object and cache it as one value.

The fix: Break large objects into Hashes with smaller fields, compress payloads, or store only the frequently-accessed subset in Redis while keeping the full object in the primary datastore.

Assuming replica reads are always up to date immediately after a write to the primary.

Why it happens: Redis replication feels instantaneous in local development with negligible network latency, hiding the asynchronous replication lag that appears under real production load.

The fix: Read from the primary for any read-after-write consistency requirement, or use WAIT to confirm replica acknowledgment before returning success for critical writes.

Designing multi-key operations in Redis Cluster without considering hash slot placement.

Why it happens: Single-node Redis development never surfaces CROSSSLOT errors, so the issue only appears after deploying to a real Cluster topology.

The fix: Use hash tags ({entityId}:field) from the start of key-schema design for any keys that will ever need to be operated on together.

Enabling AOF with appendfsync always without load-testing the latency impact.

Why it happens: Teams pick the 'safest sounding' option without benchmarking, assuming Redis's in-memory speed will absorb the fsync cost.

The fix: Benchmark appendfsync everysec first (the recommended default) and only move to always for the specific keys/use cases where a 1-second loss window is genuinely unacceptable.

Cheat Sheet

Quick-Reference Cheat Sheet

Data Structure Complexity

String GET / SETO(1)

Hash HGET / HSET / HDELO(1)

Sorted Set ZADD / ZRANGE / ZRANKO(log N)

List LPUSH / RPUSHO(1)

List LINDEX / LREM (middle access)O(N)

Set SADD / SISMEMBERO(1)

Stream XADD (append)O(1) amortized

HyperLogLog PFADD / PFCOUNTO(1) / ~12KB fixed memory

Eviction Policy Comparison

noeviction (default)Rejects writes once maxmemory hit; safest for data-of-record

allkeys-lruEvicts least-recently-used across all keys, approximated via sampling

allkeys-lfuEvicts least-frequently-used; best for hot/cold access skew

volatile-ttlEvicts keys with the nearest expiry first

volatile-lru / volatile-lfuLRU/LFU eviction limited to keys that have a TTL set

allkeys-random / volatile-randomEvicts a random key; cheapest, least predictable

RDB vs AOF Persistence Trade-offs

RDB restart speedFast (single binary snapshot load)

RDB data-loss windowUp to the snapshot interval (minutes)

AOF (everysec) data-loss windowAt most ~1 second

AOF (always) data-loss window~0, but highest write latency

AOF restart speedSlower (replays the command log)

Hybrid RDB+AOFFast restart + minimal loss window (recommended default)

Caching Pattern Quick Reference

Cache-AsideApp manages reads/writes; simplest, risk of stampede on miss

Write-ThroughSynchronous write to cache + DB; strong consistency, higher latency

Write-BehindAsync batched DB flush; lowest latency, risk of loss on cache crash

Read-ThroughCache layer owns population logic via a loader function

Replication, Cluster & HA

Replication modeAsynchronous by default (AP-leaning)

WAIT commandBlocks for N replica acknowledgments on demand

Sentinel quorumMajority agreement required before ODOWN + failover

Cluster hash slotsFixed at 16384, assigned via CRC16(key) mod 16384

CROSSSLOT fixUse hash tags {key}:suffix to co-locate related keys

Locks & Rate Limiting

Basic distributed lockSET key token NX PX <ttl>

Safe lock releaseLua script: GET check token match before DEL

Redlock quorumMajority (N/2 + 1) of independent Redis masters

Fixed-window rate limitINCR + EXPIRE per time bucket

Sliding-window rate limitZSET timestamps + ZREMRANGEBYSCORE + ZCARD

Token bucket rate limitLua script tracking token count + last refill time

Assessment Integration

Recommended Practice Quizzes on QuizCluster

Test your retention and prepare for timed live coding and MCQ technical screening rounds:

310 Quizzes

SQL & NoSQL Engines

Compare relational, key-value, and document engines including Redis's caching and persistence trade-offs.

Start Practice Test

28 Scenarios

High-Level System Design (HLD)

Practice caching layer design, sharding strategies, and distributed coordination scenarios.

Start Practice Test

Frequently Asked Questions

Is Redis a database or just a cache?

Both, depending on configuration. With persistence disabled, Redis is commonly used as a pure cache in front of a source-of-truth database. With RDB/AOF persistence, replication, and Cluster enabled, Redis is frequently used as a primary data store for use cases like session storage, leaderboards, and real-time counters.

Can Redlock guarantee perfect mutual exclusion in all failure scenarios?

No. Redlock provides strong practical guarantees under normal operating conditions and node failures, but under extreme clock drift or long process pauses (GC, VM suspension), it cannot guarantee perfect safety. Pair it with fencing tokens on the protected resource if correctness must hold even in those edge cases.

How do you scale Redis beyond what a single node's memory can hold?

Use Redis Cluster to shard data across multiple primary nodes via hash slots, each with its own replicas for high availability. Design keys with hash tags for any operations that need multiple keys to co-locate on the same shard.

When should I choose Redis over Memcached for caching?

Choose Redis when you need richer data structures (Sorted Sets, Hashes, Streams), persistence, replication/HA, pub/sub, or built-in support for patterns like distributed locks and rate limiting. Choose Memcached for the simplest possible pure key-value cache with a slightly lower per-operation memory overhead at very high scale.

Explore Other Preparation Guides

Software Engineering

How to Prepare for SDE Interview: Complete 2026 Roadmap

16 min readRead →

Java Ecosystem

How to Prepare for Java Developer Interview: Core to Spring Boot & JVM

18 min readRead →

Microservices & Distributed Systems

How to Prepare for Microservices Developer Interview: Distributed Architecture & Cloud

17 min readRead →

System Design

System Design Interview Guide: Complete 2026 Roadmap

21 min readRead →

Databases

SQL Interview Questions & Preparation Guide: Beginner to Advanced

17 min readRead →

Programming Languages

Python Interview Preparation: Complete Guide for 2026

17 min readRead →

Frontend Engineering

React Interview Preparation: React 19 & Next.js Guide

17 min readRead →

Cloud & DevOps

Kubernetes Interview Guide: Architecture, Pods, Networking & Troubleshooting

17 min readRead →

Cloud & DevOps

AWS Solutions Architect Interview Guide: Real Architecture Scenarios

17 min readRead →

Databases

Database System Design: SQL vs NoSQL, Sharding, Replication & Indexing

19 min readRead →

Microservices & Distributed Systems

Kafka Interview Guide: Architecture, Consumers, Partitions & Exactly-Once Semantics

17 min readRead →

Backend Engineering

REST API Design Interview Guide: Authentication, Pagination, Versioning & Rate Limiting

15 min readRead →

Cloud & DevOps

Docker Interview Guide: Images, Containers, Networking & Production Debugging

15 min readRead →

Programming Languages

JavaScript & TypeScript Interview Guide: From Closures to the Event Loop

17 min readRead →

Backend Engineering

Node.js Backend Interview Guide: Event Loop, Streams, APIs & Scaling

17 min readRead →

Software Engineering

Concurrency Interview Guide: Threads, Locks, Race Conditions & Deadlocks

17 min readRead →

Software Engineering

Dynamic Programming Patterns: How to Recognize and Solve DP Problems

17 min readRead →

Redis System Design Guide: Caching, Eviction, Persistence & Distributed Locks

What You Must Master to Clear This Track

Step-by-Step Study Plan

Data Structure Selection & Complexity Analysis

Cache Consistency Strategies & Durability Trade-offs

High Availability, Sharding & Redlock

1. Redis Core Data Structures & Time Complexity

2. Caching Patterns: Cache-Aside, Write-Through, Write-Behind & Eviction

3. Persistence: RDB Snapshots vs AOF & Durability Trade-offs

4. Replication, High Availability, Distributed Locks & Rate Limiting

Eliminating Overselling and Database Overload During Flash Sales at a Mid-Size E-Commerce Platform

Top Must-Know Interview Questions & Model Answers

Q1: Why does Redis use a skip list combined with a hash table for Sorted Sets instead of just a balanced tree?

Q2: How would you model a real-time leaderboard for 10 million users using Redis?

Q3: What is the practical difference between using Redis Lists and Redis Streams as a message queue?

Q4: Why should you avoid storing one very large String value (multiple megabytes) as a single Redis key?

Q5: What is the HyperLogLog data structure in Redis, and when would you use it over a Set?

Q6: Explain the cache-aside pattern and its main weakness during a cold start or cache flush.

Q7: Compare write-through and write-behind caching in terms of consistency and failure risk.

Q8: When would you choose read-through caching over application-managed cache-aside?

Q9: How does Redis's default maxmemory-policy of noeviction behave once memory is full, and why is that dangerous?

Q10: What is the difference between allkeys-lru and volatile-lru eviction policies?

Q11: How does Redis approximate LRU eviction without maintaining a true, fully-ordered LRU linked list?

Q12: When would LFU (Least Frequently Used) eviction outperform LRU for a caching workload?

Q13: What happens during Redis's BGSAVE, and why doesn't it block client commands?

Q14: Compare the three AOF appendfsync options and their durability/performance trade-offs.

Q15: Why would a team choose hybrid RDB+AOF persistence instead of just one mechanism?

Q16: What's the risk of enabling only RDB persistence with default snapshot intervals (e.g. save 900 1)?

Q17: How does Redis Sentinel decide a primary is actually down before triggering failover?

Q18: In Redis Cluster, why are keys partitioned into exactly 16384 hash slots instead of using simple consistent hashing?

Q19: What causes a CROSSSLOT error in Redis Cluster, and how do you avoid it for multi-key operations?

Q20: Why is asynchronous replication in Redis considered an AP-leaning trade-off rather than strongly consistent?

Q21: How would you size and design Redis Cluster nodes for a 50 million session, multi-region user base?

Q22: What problem does the Redlock algorithm solve, and what is its core mechanism?

Q23: What is the main criticism of Redlock, and how do fencing tokens address it?

Q24: Why should a single-instance Redis lock (SET NX PX) be considered insufficient for critical distributed coordination?

Q25: How would you implement a sliding-window rate limiter using a Redis Sorted Set?

Q26: Compare token bucket and fixed-window counter approaches for Redis-based rate limiting.

Q27: Why are Redis transactions (MULTI/EXEC) not equivalent to full ACID database transactions?

Q28: Why is Redis effectively single-threaded for command execution, and how does that affect design decisions?

Q29: What is the N+1 cache invalidation problem, and how do you handle invalidating a cache entry that depends on multiple upstream tables?

Q30: How do you decide the right TTL for a cached value in a system design interview?

Mistakes That Sink Otherwise Strong Candidates

Quick-Reference Cheat Sheet

Recommended Practice Quizzes on QuizCluster

SQL & NoSQL Engines

High-Level System Design (HLD)

Frequently Asked Questions

Is Redis a database or just a cache?

Can Redlock guarantee perfect mutual exclusion in all failure scenarios?

How do you scale Redis beyond what a single node's memory can hold?

When should I choose Redis over Memcached for caching?

Explore Other Preparation Guides