Redis Fundamentals

Introduction

Redis is an in-memory data structure store used as cache, session store, rate limiter, pub/sub bus, and lightweight queue. Sub-millisecond latency makes it essential in HLD for read-heavy APIs, leaderboards, distributed locks, and idempotency keys.

Redis is not a replacement for PostgreSQL — it is a performance and coordination layer with optional persistence (RDB/AOF). Interviews expect cache-aside pattern, TTL discipline, eviction policies, and cluster mode for horizontal scale.

This lesson covers Redis placement in architecture, data types for common patterns, and HA with Sentinel/Cluster.

Understanding the topic

Key concepts

• Strings: cache blobs, counters (INCR), distributed locks (SET NX EX).
• Hashes: session objects, field-level updates without full JSON rewrite.
• Sorted sets: leaderboards, delayed job queues (score = timestamp).
• TTL on every cache key — unbounded keys cause OOM.
• Eviction: allkeys-lru vs volatile-lru when maxmemory reached.
• Redis Cluster: 16384 hash slots sharded across nodes; MOVED redirects.

flowchart LR
  App -->|GET SET| Redis[(Redis)]
  Redis -->|miss| DB[(PostgreSQL)]

Internal architecture

Architecture overview

flowchart LR
  App -->|GET SET| Redis[(Redis)]
  Redis -->|miss| DB[(PostgreSQL)]

Step-by-step explanation

1. App cache-aside: GET redis → miss → SELECT postgres → SETEX with TTL.
2. Session store: hash per sessionId, TTL aligned with JWT expiry.
3. Rate limiter: INCR key with EX window at API gateway.
4. Pub/Sub for ephemeral notifications — not durable; use Kafka for that.
5. Primary-replica Redis with Sentinel failover for HA.
6. Large values (>100KB) hurt performance — compress or store reference in Redis.

Informative example

Spring Data Redis cache-aside for product catalog with TTL jitter:

@Service
public class ProductCacheService {
    private static final Duration TTL = Duration.ofMinutes(10);
    private final StringRedisTemplate redis;
    private final ProductRepository db;
    private final ObjectMapper mapper;

    public ProductCacheService(StringRedisTemplate redis, ProductRepository db, ObjectMapper mapper) {
        this.redis = redis;
        this.db = db;
        this.mapper = mapper;
    }

    public Product get(String id) throws JsonProcessingException {
        String key = "product:" + id;
        String cached = redis.opsForValue().get(key);
        if (cached != null) return mapper.readValue(cached, Product.class);
        Product p = db.findById(id).orElseThrow();
        long jitter = ThreadLocalRandom.current().nextLong(60);
        redis.opsForValue().set(key, mapper.writeValueAsString(p), TTL.plusSeconds(jitter));
        return p;
    }
}

TTL jitter reduces cache stampede. Invalidate on admin update via DEL or versioned keys.

Real-world use

Real-world use cases

• E-commerce flash sale inventory counters with DECR and floor at zero.
• Banking session and OTP rate limits.
• Social leaderboards with ZINCRBY.
• Ride-hailing driver location GEOADD (Redis geo) hot path.

Best practices

• Always set maxmemory and eviction policy in production.
• Use connection pooling (Lettuce) — one connection per request fails at scale.
• Monitor hit ratio, evicted keys, and slowlog.
• Hash tag {userId} in cluster for multi-key transactions on same slot.
• Never store sole copy of financial truth without durable backing.
• Prefer Redis for ephemera; PostgreSQL remains source of truth.

Common mistakes

• No TTL — memory fills, evictions kill hot keys randomly.
• KEYS * in production — blocks event loop.
• Large JSON blobs for objects better stored as hashes field-wise.
• Using Pub/Sub as durable queue — messages lost if no subscriber.
• Ignoring single-threaded per shard — hot key bottleneck on one slot.

Advanced interview questions

Summary

Redis accelerates reads and enables real-time coordination. Cache-aside with TTL is the dominant integration pattern. Choose data types (hash, zset) matching access patterns. Cluster and Sentinel provide scale and HA. Redis complements SQL — not replaces transactional storage. Cache strategies lesson expands invalidation and patterns.