Redis Interview Questions India 2026: Caching, Data Structures, and Distributed Systems

Redis data structures:

1. String: The most basic Redis data structure. Stores text, numbers, or binary data up to 512 MB. Operations: SET, GET, INCR (atomic increment; for counters), APPEND, STRLEN. TTL support: SET key value EX 3600 (expires in 1 hour). Use for: simple key-value caching, counters (page views, API request counts), session tokens.

2. Hash: A map of field-value pairs (like a JSON object). Operations: HSET, HGET, HMGET, HGETALL, HDEL, HINCRBY. Use for: storing user profiles or session data as individual fields (allows updating one field without fetching the entire object).

3. List: Ordered linked list; supports O(1) push/pop from either end. LPUSH/RPUSH: push to left/right. LPOP/RPOP: pop from left/right. LRANGE: get a range of elements. Use for: task queues (RPUSH to enqueue; BLPOP to dequeue in a blocking way), activity feeds (recent N items).

4. Set: Unordered collection of unique strings. SADD, SISMEMBER, SMEMBERS, SUNION, SINTER, SDIFF. Use for: tracking unique visitors, storing tags, implementing friends-of-friends via set intersection.

5. Sorted Set (ZSet): Like a Set but each member has a score. Members are ordered by score. ZADD, ZRANGE, ZREVRANGE, ZRANK, ZSCORE. Use for: leaderboards (score = points; ZREVRANGE to get top N), time-series data (score = timestamp), rate limiting with a sliding window.

6. HyperLogLog: Probabilistic data structure for approximate cardinality estimation (count unique values) using constant memory. PFADD, PFCOUNT. Accurate to within 0.81% with 12 KB of memory. Use for: counting unique visitors when exact counts are not needed.

7. Stream: Append-only log (similar to Kafka but simpler). XADD, XREAD, XREADGROUP. Use for: lightweight event streaming, audit logs.

Redis caching patterns:

1. Cache-aside (lazy loading): The most common caching pattern. Flow: 1. Application checks the cache for the key 2. Cache hit: return the value from the cache 3. Cache miss: fetch from the database, store in the cache with a TTL, return the value Advantages: only caches what is actually read (no wasted cache space). Disadvantages: first read after a cache miss is slower; the cache can become stale (the database is updated but the cache is not).

2. Write-through: Every write goes to both the cache and the database simultaneously. The cache is always in sync with the database. Advantages: no stale data. Disadvantages: every write is slightly slower (two writes instead of one); the cache fills with data that may never be read.

3. Write-behind (write-back): Writes go to the cache first; the cache asynchronously writes to the database. Very fast writes; the application sees the write immediately. Advantages: very fast write path. Disadvantages: risk of data loss if the cache crashes before persisting to the database; complex implementation.

4. TTL and cache invalidation: TTL (Time-To-Live): automatically expire cached values after a period. The simplest form of cache invalidation. Explicit invalidation: when data changes, delete the corresponding cache key. This is simpler but requires the application to know which cache keys to invalidate. Event-driven invalidation: use Redis keyspace notifications or a change data capture pipeline (Debezium) to automatically invalidate cache entries when the database changes.

Advanced Redis patterns:

1. Pub/Sub: Redis Pub/Sub allows message broadcasting. Publishers send messages to channels; subscribers receive messages from channels. PUBLISH channel message; SUBSCRIBE channel. Limitations: messages are not persisted (if a subscriber is offline, it misses messages); no delivery guarantees. Use Redis Streams for durable messaging. Use Pub/Sub for: real-time notifications, cache invalidation broadcasts (publish 'invalidate product:123' to all application servers).

2. Distributed locks: Redis is commonly used for distributed locks in microservices: SET lockkey uniqueid NX PX 30000 (SET only if Not eXists, with a 30-second expiry). The lock is held while the value is set; released by DEL (but only if the value matches the unique_id; prevents releasing another process's lock). Redlock algorithm: acquire the lock on a majority of independent Redis nodes for stronger guarantees.

3. Rate limiting: Common rate limiting pattern with Redis sorted sets (sliding window): 1. ZREMRANGEBYSCORE key 0 (now - window) — remove expired entries 2. ZCARD key — count current entries 3. If count < limit: ZADD key now now — add current request; proceed 4. If count >= limit: reject the request Simpler approach with INCR and TTL (fixed window): INCR requestcountfor_user; set TTL on first increment; compare count to limit.

4. Redis Cluster vs Redis Sentinel: Redis Sentinel: monitors a master/replica setup; promotes a replica to master if the master fails. Provides high availability but not horizontal scaling (data is on one master). Redis Cluster: automatically shards data across multiple masters (each master has a subset of the 16,384 hash slots). Provides both horizontal scaling (higher throughput) and high availability.

Redis in production:

1. Memory management: Redis is an in-memory store; its size is limited by available RAM. maxmemory: set the maximum memory Redis can use. maxmemory-policy: what to do when the limit is reached. Eviction policies: allkeys-lru (evict the least recently used key; good for pure cache use case), volatile-lru (evict LRU keys that have a TTL), noeviction (reject writes; never use for a pure cache).

2. Persistence: RDB (Redis Database Backup): periodic snapshots; smaller file; faster restart but data loss since the last snapshot. AOF (Append-Only File): logs every write operation; more durable; recommended for use cases where data loss is not acceptable. Most production Redis setups: AOF with everysec fsync (write to disk every second; at most 1 second of data loss) for balance between performance and durability.

3. Redis vs Memcached: When to choose Redis over Memcached: Redis supports more data types (lists, sets, sorted sets; Memcached only supports strings), persistence, pub/sub, scripting (Lua), and cluster mode. Memcached is slightly faster for simple string caching and uses less memory per key, but these advantages rarely matter in practice. In 2026, Redis is the default choice for virtually all new projects.

4. Monitoring Redis: Key metrics: usedmemory (current memory usage), connectedclients, keyspacehits and keyspacemisses (cache hit rate = hits / (hits + misses)), evicted_keys (if > 0, your maxmemory is too low). Tools: Redis CLI's INFO command, Redis Insights (Redis's official GUI), Prometheus + Redis Exporter + Grafana.