Redis Home

Introduction

Welcome to Redis Mastery — a practical course for backend engineers who need Redis in production, not just for local caching demos.

Redis is an in-memory data structure server. Teams use it for session stores, API caches, rate limiters, leaderboards, pub/sub, and real-time features where PostgreSQL or MongoDB would be too slow or too expensive at scale.

This course takes you from fundamentals through clustering, Spring Boot integration, and production troubleshooting. Each lesson is designed to be read in about 10 minutes and applied the same day.

Understanding the topic

Key concepts

• Redis stores data in RAM — typical latency is sub-millisecond vs milliseconds for disk databases.
• It is single-threaded per shard: one command runs at a time, which simplifies atomicity but makes slow commands dangerous.
• Rich types (strings, hashes, sorted sets, streams) let you model problems without serializing everything to JSON.
• Persistence (RDB/AOF), replication, Sentinel, and Cluster are optional layers for durability and scale.
• Spring Boot apps typically connect via Lettuce and Spring Data Redis.
• Six phases: fundamentals → data structures → advanced patterns → HA → Spring Boot → production ops.

flowchart LR
  Client -->|RESP| Redis
  Redis -->|result| Client

Step-by-step explanation

1. Application sends commands over TCP using the RESP protocol.
2. Redis parses the command on a single event-loop thread.
3. The command runs atomically against the in-memory keyspace.
4. Optional background work handles persistence, replication, and lazy freeing.
5. The result is returned to the client; pipelining batches many commands in one round trip.

Syntax reference

Quick sanity check when starting the course:

• PING — verify connectivity.
• INFO — server metadata.
• SET … EX — set with TTL (always use TTL on cache keys).

redis-cli ping          # PONG
redis-cli INFO server   # version, uptime
redis-cli SET course:redis "started" EX 86400

Informative example

Minimal cache-aside pattern — the most common Redis use case in microservices:

@Service
public class ProductCacheService {
    private final StringRedisTemplate redis;
    private final ProductRepository db;

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

    public Product getById(String id) {
        String key = "product:" + id;
        String cached = redis.opsForValue().get(key);
        if (cached != null) {
            return parse(cached);
        }
        Product product = db.findById(id).orElseThrow();
        redis.opsForValue().set(key, serialize(product), Duration.ofMinutes(30));
        return product;
    }
}

Check cache first, load DB on miss, write back with TTL. This pattern appears in catalog, user profile, and config services.

Real-world use

Real-world use cases

• Session storage (Netflix-style) — hash per session with TTL.
• Product catalog cache (e-commerce) — string JSON keyed by SKU.
• Rate limiting — INCR with EXPIRE or Lua sliding window.
• Leaderboards — sorted sets with ZADD/ZREVRANGE.
• Driver location (Uber-style) — GEOADD and GEORADIUS.

Best practices

• Always set maxmemory and an eviction policy before production traffic.
• Use TTL on every cache key — unbounded keys cause OOM.
• Prefix keys: service:entity:id (e.g. session:user:42).
• Prefer pipelining for bulk reads/writes.
• Never run KEYS * in production — use SCAN.
• Monitor memory usage, hit rate, and slowlog.
• Test failover and backup restore quarterly.

Common mistakes

• Treating Redis as durable storage without configuring RDB or AOF.
• Caching without an invalidation or TTL strategy.
• Using one giant JSON string when a hash or sorted set fits better.
• Ignoring connection pool sizing in Spring (too few = starvation).
• Running blocking commands (KEYS, FLUSHALL) on shared prod instances.

Advanced interview questions

Summary

Redis is a fast in-memory data structure server — not just a simple cache.