Redis shows up in almost every design diagram, usually as a small box labelled "cache". That undersells it. Redis is an in-memory server for data structures: strings, hashes, lists, sets, sorted sets, streams and a few more. You send it a command, it changes a structure in RAM, and it answers in well under a millisecond.
If you skipped straight here: Module 3 covered caching patterns like cache-aside and TTLs, Module 13 covered leader-follower replication, and Module 14 covered hash partitioning. This lesson shows how Redis implements those ideas, and where it bends.
What Redis is best at
Redis is the right tool when you need small, hot, shared state that many servers read and write very fast.
| Job | Why Redis fits |
|---|---|
| Cache in front of a database | Sub-millisecond reads, TTLs built in |
| Rate limit counters | Atomic INCR with an expiry |
| Sessions and short-lived tokens | Keys that delete themselves |
| Leaderboards and "top N" | Sorted sets keep order for you |
| Nearby search over moving things | Geo commands on top of sorted sets |
| Light job queues and event fan-out | Lists, streams, pub/sub |
A single Redis node on ordinary hardware handles roughly 100,000 to 200,000 simple commands a second. That number is the reason it appears everywhere.