Step 1 • Setup
Redis Setup — CLI, Desktop GUI, and Client Libraries beginner Redis is an in-memory data structure store — database, cache, message broker, and streaming engine in one. Install with Docker (docker run -d -p 6379:6379 redis) or Redis Stack (includes RedisInsight GUI and modules). redis-cli is the command-line interface — connect with redis-cli, run PING, SET, GET. RedisInsight is the official GUI for visualizing keys, running commands, and profiling. Client libraries: ioredis or node-redis for Node.js, redis-py for Python, Lettuce for Java. Understand that Redis stores everything in memory — this is why it's fast, and also why capacity planning matters.
2h Step 2 • Data Structures
Strings — The Universal Data Type beginner Strings are Redis's most basic type — they hold text, integers, or binary data (up to 512MB). Core commands: SET, GET, DEL, EXISTS, MSET/MGET (multiple keys atomically), APPEND, STRLEN, GETSET (old pattern — replaced by GETDEL/GETEX). Integer commands: INCR, INCRBY, DECR, DECRBY — atomic, no race conditions, perfect for counters and rate limiting. INCRBYFLOAT for floating point. NX flag (SET only if not exists), XX flag (SET only if exists), EX/PX for expiry. SETNX is the old atomic set-if-not-exists — use SET key value NX EX seconds in modern Redis.
4h Step 3 • Data Structures
Hashes, Lists, Sets, and Sorted Sets beginner Redis data structures map directly to real-world patterns. Hash (HSET/HGET/HMGET/HGETALL/HINCRBY) — store objects as field-value pairs, cheaper than one key per field. List (LPUSH/RPUSH/LPOP/RPOP/LRANGE/LLEN/LPOS) — ordered, allows duplicates, great for queues (RPUSH + LPOP) and recent-activity lists. Set (SADD/SMEMBERS/SISMEMBER/SUNION/SINTER/SDIFF) — unordered, unique values, great for tags, followers, and set operations. Sorted Set / ZSet (ZADD/ZRANGE/ZRANGEBYSCORE/ZRANK/ZREM/ZINCRBY) — ordered by score, great for leaderboards, priority queues, and time-series indexing.
6h Step 4 • Data Structures
Bitmaps, HyperLogLog, and Geospatial intermediate Redis has three additional specialized data types that are extremely efficient for specific problems. Bitmaps — not a separate type but bit-level operations on Strings. SETBIT key offset 1, GETBIT, BITCOUNT (count set bits), BITOP (AND/OR/XOR/NOT across keys). Use case: tracking user activity per day (one bit per user per day — storing 100M users' daily activity costs only 12.5MB). HyperLogLog — probabilistic cardinality estimation with < 1% error rate using fixed 12KB memory regardless of the set size. PFADD adds items, PFCOUNT returns estimated unique count, PFMERGE combines HLLs. Use case: counting unique visitors (can't use a Set — too much memory at scale). Geospatial — GEOADD (store lat/lon), GEODIST (distance between points), GEORADIUS/GEOSEARCH (find points within radius). Internally stored as a Sorted Set with encoded score.
4h Step 5 • Foundations
Expiry, TTL, and Key Eviction Policies beginner Expiry is fundamental to Redis's role as a cache. EXPIRE key seconds (set TTL), EXPIREAT key timestamp (expire at Unix timestamp), TTL key (seconds remaining — -1 means no expiry, -2 means key doesn't exist), PERSIST key (remove expiry). PEXPIRE/PEXPIREAT/PTTL for millisecond precision. Eviction policies (set in redis.conf: maxmemory-policy) control what happens when Redis reaches its memory limit — allkeys-lru (evict least recently used from all keys), volatile-lru (LRU from keys with TTL), allkeys-lfu (least frequently used), noeviction (return errors — dangerous for a cache). Set maxmemory to prevent OOM.
4h Step 6 • Messaging
Pub/Sub — Real-Time Messaging intermediate Redis Pub/Sub enables fire-and-forget messaging — publishers send to channels, all current subscribers receive the message. SUBSCRIBE channel (block and listen), PUBLISH channel message (send to all subscribers), PSUBSCRIBE pattern (wildcard subscription — notifications:* for all notification channels), UNSUBSCRIBE. Key limitations: messages are not persisted (missed if subscriber is offline), no consumer groups, no acknowledgement, no message history. Use Pub/Sub for real-time notifications, live dashboards, and chat — but use Redis Streams for anything requiring durability or exactly-once processing.
4h Step 7 • Messaging
Redis Streams — Durable Event Log intermediate Redis Streams (added in Redis 5.0) is an append-only log like Apache Kafka but simpler. XADD adds entries with auto-generated IDs (timestamp-sequence), XREAD reads sequentially, XRANGE reads by ID range. Consumer groups (XGROUP CREATE, XREADGROUP) allow multiple competing consumers where each message is delivered to one consumer — like Kafka consumer groups. XACK acknowledges processing, XPENDING shows unacknowledged messages, XCLAIM transfers stale messages to another consumer. Streams persist across restarts (unlike Pub/Sub). MAXLEN to cap stream size. Use for reliable job queues, audit logs, and event sourcing.
6h Step 8 • Caching
Caching Patterns — Cache-Aside, Write-Through, and More intermediate Caching is Redis's most common use case but the patterns matter. Cache-aside (lazy loading) — app checks cache first, on miss fetches from DB and populates cache (most flexible, risk of thundering herd). Write-through — write to cache and DB simultaneously (consistent, higher write latency). Write-behind (write-back) — write to cache immediately, asynchronously write to DB (fast writes, risk of data loss). Read-through — cache itself handles DB reads (simpler app code). Cache stampede prevention — probabilistic early expiry, mutex lock, or background refresh. Cache warming on startup. Key naming conventions — prefix:entity:id pattern.
6h Step 9 • Advanced
Lua Scripts and Atomic Operations intermediate Redis executes Lua scripts atomically — the entire script runs without interruption from other clients. This makes Lua the solution for operations that must be atomic but span multiple keys or commands (which MULTI/EXEC can't guarantee across the network). EVAL script numkeys key [key...] arg [arg...], EVALSHA sha numkeys (reuse a cached script). Use KEYS[1] and ARGV[1] to access keys and args. SCRIPT LOAD to cache a script and get its SHA. Common patterns: atomic check-and-set, rate limiter with sliding window, distributed semaphore. Note: Lua scripts block all other operations — keep them short.
5h Step 10 • Reliability
Transactions with MULTI/EXEC and Optimistic Locking intermediate Redis transactions batch commands with MULTI/EXEC — all queued commands execute atomically in sequence. DISCARD abandons the queue. Important: Redis transactions do NOT roll back on command errors (unlike SQL) — they run all queued commands even if one fails. This limits their usefulness for complex business logic. WATCH key implements optimistic locking — if the watched key changes before EXEC, the transaction is aborted (EXEC returns nil). The typical pattern: WATCH → read value → MULTI → update commands → EXEC — retry if nil. For true atomicity across multiple keys with rollback, use Lua scripts instead.
4h Step 11 • intermediate
Pipelining & Batch Commands intermediate Batch multiple Redis commands into a single round trip with pipelining — dramatically reduces network latency for bulk operations. Key difference from MULTI/EXEC: pipelines are not atomic. Use MGET/MSET for simple multi-key operations. Benchmark pipeline vs sequential performance. Use client-side pipelining in Node.js (ioredis), Python (redis-py), and Java (Jedis).
3h Step 12 • Data Durability
Persistence — RDB Snapshots and AOF intermediate Redis is in-memory but can persist data to disk. Two mechanisms: RDB (Redis Database) — point-in-time snapshots saved to a .rdb file (SAVE is blocking, BGSAVE is background — triggered by config like save 900 1 = save every 900s if 1+ key changed). AOF (Append-Only File) — logs every write operation, replayed on restart (appendonly yes, appendfsync policy: always = safest, everysec = balanced, no = fastest but risky). AOF + RDB together: RDB for fast recovery, AOF for minimal data loss. Redis 7.0 RDB-AOF hybrid format. For a pure cache where data loss is acceptable, disable both.
5h Step 13 • High Availability
Replication — Primary and Replicas intermediate Redis replication is asynchronous — replicas copy data from the primary after a partial or full sync. REPLICAOF primary-host port sets up a replica. Replicas are read-only by default — route read traffic to replicas to scale reads. Redis Sentinel monitors primaries and replicas, detects failures, and performs automatic failover — promoting a replica to primary and updating clients. Sentinel quorum (minimum votes to agree on failure) prevents split-brain. Configure replica-priority to influence which replica becomes primary. For zero-downtime failover clients must support Sentinel (most client libraries do).
5h Step 14 • High Availability
Redis Cluster — Horizontal Sharding advanced Redis Cluster shards data across multiple nodes — a minimum of 3 primary nodes (each with a replica = 6 nodes). Keys are assigned to one of 16,384 hash slots via CRC16(key) % 16384. Multi-key operations require keys in the same slot — use hash tags ({user}:profile and {user}:session are colocated. Cluster-aware client libraries handle routing (ioredis cluster mode, Lettuce, redis-py-cluster). Cluster auto-shards when you add nodes (online resharding with redis-cli --cluster reshard). Redis Cluster topology: CLUSTER INFO, CLUSTER NODES. Managed alternatives: Redis Cloud, ElastiCache (Cluster Mode Enabled).
6h Step 15 • Security
Security and Access Control intermediate A default Redis install has no authentication and is only protected by your network. ACL (Access Control Lists, Redis 6+) replaces the single requirepass password — define users with specific command and key permissions (ACL SETUSER dev on >password ~cache:* +GET +SET +DEL). ACL LOG captures denied commands. TLS for in-transit encryption (configure tls-port, tls-cert-file). Network security — bind to specific interfaces (bind 127.0.0.1), disable CONFIG and DEBUG commands in production with rename-command. Never expose Redis to the public internet without TLS and ACL. Redis Cloud and ElastiCache handle most of this for you.
4h Step 16 • Production
Monitoring, Profiling, and Production Operations advanced INFO all returns 200+ metrics — memory used, hit rate (keyspace_hits vs keyspace_misses), connected clients, replication lag, and evicted keys. MONITOR streams every command in real time (dev only — huge performance impact). SLOWLOG GET lists commands exceeding the slowlog-log-slower-than threshold. LATENCY MONITOR tracks latency spikes. redis-cli --bigkeys finds large keys that could cause latency. redis-cli --memkeys shows memory usage per key. Datadog, Prometheus (redis_exporter), and Grafana for production monitoring. Key metrics to alert on: eviction rate, memory usage >80%, replication lag >10s, hit rate <90%.
5h 