In-Memory Caching (Redis)
A single-threaded, in-memory data structure store, fast enough to answer in microseconds — with a real durability trade-off underneath.
Overview
Redis is a single-threaded, in-memory key-value data structure store, commonly used for caching, session storage, and rate limiting — fast because it lives entirely in RAM, and versatile because it offers real data structures (lists, sets, sorted sets, hashes), not just plain strings.
Why It Exists
A relational database, even one with a generous RAM cache, still carries disk-backed-engine overhead on every read. For data that's read constantly, changes relatively rarely, and can tolerate being lost in the rare case of a crash, an in-memory store answers in well under a millisecond — a speed a disk-based engine structurally cannot match, for exactly the reasons covered back in the storage latency ladder.
Real World Example
A user's session token is stored in Redis on login and checked on every single subsequent request to verify they're authenticated. At that request volume, hitting a disk-backed database for every check would be far too slow and far too much load; Redis answers in microseconds instead. A leaderboard feature uses Redis's sorted-set data structure to keep scores ranked with efficient updates, something that would take considerably more application logic to replicate correctly in a relational database.
Example Data
A leaderboard as a Redis sorted set — kept ranked automatically
| Rank | Member | Score |
|---|---|---|
| 1 | player_204 | 9,850 |
| 2 | player_089 | 9,410 |
| 3 | player_337 | 9,200 |
What Makes Redis What It Is
Native Data Structures, Not Just Strings
Lists, sets, sorted sets, and hashes are built in and manipulated with dedicated commands — operations like ranking a leaderboard or checking set membership don't need to be reimplemented in application code.
Single-Threaded by Design
Every command executes one at a time on a single thread. This makes Redis simple to reason about (no locking needed) but means one very expensive command can briefly block every other client.
RDB — Point-in-Time Snapshots
Periodically dumps the entire dataset to disk as a binary snapshot. Fast to restart from, but anything written since the last snapshot is lost if Redis crashes.
AOF — Append-Only Command Log
Logs every write command so it can be replayed after a restart, offering better durability than RDB alone — at the cost of a larger log file and somewhat slower restarts as it replays.
Diagram
Redis stays in RAM for speed; persistence is a separate, configurable safety net
App writes to Redis
stored in RAM
RDB
periodic full snapshot
AOF
every write command logged
On restart, Redis reloads from RDB/AOF
Common Mistakes
Treating Redis as a guaranteed-durable primary datastore
Why: Even with AOF enabled, Redis prioritizes speed, and its persistence mechanisms trade off durability in ways a disk-based ACID database doesn't — a crash between a write and the next fsync can still lose data.
Fix: Use Redis as a cache or ephemeral store backed by a real database as the source of truth, unless you've specifically configured and tested its durability guarantees for your actual tolerance.
Storing very large values in a single Redis key, or running full-scan commands in production
Why: Since Redis is single-threaded, one very expensive command — a huge value, or a full-database-scanning command like KEYS — blocks every other client until it finishes.
Fix: Keep values reasonably sized, avoid KEYS in production, and prefer the cursor-based SCAN command instead.
Not planning for what happens when Redis is temporarily unavailable
Why: Since Redis often sits on the hot path — session checks, rate limits — an outage or restart can take down or badly degrade the whole application if there's no fallback.
Fix: Design a degraded-but-functional fallback (or fail gracefully) for the cases where Redis is temporarily unreachable.
Interview Questions
Why is Redis so much faster than a typical relational database for simple lookups?
Redis keeps its entire dataset in RAM and is optimized purely for key-value and data-structure operations, avoiding the disk I/O and general-purpose query planning overhead a relational database pays even for a simple lookup.
What's the difference between RDB and AOF persistence?
RDB periodically writes the entire dataset to disk as a point-in-time binary snapshot — fast to restore from, but anything written since the last snapshot is lost on a crash. AOF logs every write command as it happens, offering better durability at the cost of a larger log and slower replay on restart.
Redis is single-threaded. How does that affect which workloads and commands you should avoid running against it in production?
Because every command runs sequentially on one thread, any single expensive operation — a command that scans the whole keyspace, an operation on a very large value, or a poorly-chosen Lua script — blocks every other client for its duration. This means production usage should avoid commands like KEYS in favor of SCAN, keep individual values reasonably sized, and be cautious with any operation whose cost scales with dataset size rather than being constant-time.
Production Best Practices
Do
✓Use Redis as a cache or ephemeral store, with a real database as the source of truth.
✓Prefer SCAN over KEYS, and keep individual values reasonably sized.
✓Design a fallback path for when Redis is temporarily unreachable.
Don't
✗Don't rely on Redis alone as a durable system of record without deliberately configuring and testing AOF.
✗Don't run full-keyspace-scanning commands against a production Redis instance.
✗Don't let the entire application go down just because Redis briefly restarts.
Comparison
| Mechanism | Durability | Restart Speed | |
|---|---|---|---|
| RDB | Periodic full snapshot | Loses writes since last snapshot | Fast — loads one file |
| AOF | Every write command logged | Loses at most a fraction of a second | Slower — replays the log |