Redis: The In-Memory Swiss Army Knife — FM India

Redis is the odd one out in this list. You don't store your application's source-of-truth data in it. You run it alongside your real database (usually Postgres) to make things fast: cache expensive results, hold sessions, count rate limits, run simple queues. Because it keeps data in memory, it answers in well under a millisecond.

What it is

Redis is an in-memory key-value store. At its simplest, it's a giant dictionary: a key maps to a value, and you get or set by key, fast. But its values aren't just strings; Redis has a handful of built-in data structures, and picking the right one is most of the skill.

SET session:abc123 "user_42"  EX 3600   # value with a 1-hour expiry
GET session:abc123                       # -> "user_42"
INCR rate:user_42:minute                 # atomic counter, great for rate limits
EXPIRE rate:user_42:minute 60            # auto-clears after 60s

That EX / EXPIRE (a time-to-live) is a Redis signature: keys can expire on their own, which is exactly what you want for caches and counters.

The data structures that matter

Functional · what it does

Strings — basic caching and flags. SET key value EX 60.
Hashes — store an object's fields under one key. Good for a cached record.
Sorted sets — values ranked by a score, kept in order. Leaderboards, time-ordered feeds.
Lists — push/pop from either end. Simple queues.

Non-functional · what it must survive

Sub-millisecond — it's RAM, so reads and writes are tiny.
Atomic operations — INCR and friends are atomic, so counters are correct under concurrency.
TTL built in — keys expire on their own, perfect for caches.
Pub/sub — lightweight message broadcasting between processes.

The patterns you'll actually use

Redis earns its place through a small set of jobs, each a recurring pattern from the rest of this course:

Caching (cache-aside). Check Redis first; on a miss, read Postgres and store the result with a TTL. The next read is instant and never touches the database.
Sessions. Store login sessions here so any app server can look them up fast, and so logout is instant (delete the key).
Rate limiting. An atomic INCR with a TTL is exactly a per-user request counter, the distributed rate limiter in one command.
Leaderboards / feeds. Sorted sets keep items ranked by score automatically.
Queues. Lists (or Redis Streams for durable ones) move background jobs between producers and workers.

When (not) to use it

Memory is the constraint, and it's not your source of truth

Everything lives in RAM, which is fast but limited and more expensive than disk, so Redis is for data that's small, hot, or disposable, not your entire dataset. Redis can write to disk in two ways: RDB takes periodic point-in-time snapshots (compact, fast restarts, but you lose whatever changed since the last snapshot if it crashes), and AOF logs every write command and replays it on startup (more durable, larger files). Production setups often run both. But even with persistence on, treat cached data as losable: if Redis restarts and a cache is gone, your app should just rebuild it from Postgres. Never make Redis the only place a piece of important data exists unless you've deliberately turned on durability and accepted the trade-offs.

When it's the wrong tool

Don't reach for Redis when you need rich queries (it's key-lookup, not SQL), strong durability for your primary data, or to store large datasets that won't fit comfortably in memory. Those are jobs for your real database. Redis is the accelerator, not the engine.

The one-liner

Redis is a sub-millisecond in-memory key-value store you run beside your real database to make things fast: caching, sessions, rate-limit counters, queues, leaderboards. Pick the right data structure for the job, lean on TTLs, and treat its data as rebuildable. It's the cache and the scalpel, never the source of truth.

Test yourself

Questions· say the answer out loud before you open it. If you can't, the chapter isn't done.

QHow is Redis different from a database like Postgres, and how do you use it?+

Redis is an in-memory key-value store, so it's sub-millisecond but limited by RAM and not your source of truth. You use it alongside Postgres, not instead of it, to take load off the database: caching, sessions, rate-limit counters, queues, leaderboards.

QWhat makes Redis good for rate limiting?+

Atomic operations plus TTLs. INCR increments a counter atomically (correct even under concurrent requests), and EXPIRE makes the key auto-clear after the window. So a per-user, per-minute limit is just INCR a key and set a 60-second TTL, returning 429 over the limit.

QWhat should you NOT use Redis for?+

Rich queries (it's key-lookup, not SQL), durable storage of your primary data, or datasets too large to fit comfortably in memory. It can persist to disk via RDB snapshots or the AOF write log, but treat its contents as rebuildable from your real database; never make Redis the only home of important data unless you've deliberately configured and accepted durability trade-offs.