Key Technologies
Redis
The in-memory Swiss-army knife — what Redis is, the data structures that make it more than a cache, and the handful of jobs it does better than anything else: caching, rate limiting, leaderboards, locks and pub/sub.
Redis is an in-memory data store. Because it keeps data in RAM, reads and writes are measured in microseconds and it handles ~100k+ operations per second on a single node. People call it "a cache," but it's really a toolbox of data structures you reach for whenever you need something fast and shared across all your servers.
Why it's more than a cache
Redis stores typed values, not just strings, and each type comes with atomic operations that solve a specific problem:
| Structure | Buys you | Classic use |
|---|---|---|
String + INCR | Atomic counters | Rate limiting, view counts |
| Hash | A small object by field | Session data, a cached row |
| Sorted set | Ranking by score | Leaderboards, "top K", priority queues |
| Set | Membership, uniqueness | "Seen" sets, unique visitors |
| List | A queue | Simple job queues |
SET NX + TTL | A distributed lock | "Only one worker does this" |
The atomicity matters: INCR increments and returns in one step, so a rate limiter built on it is race-free across all your servers.
The jobs it's best at
- Caching — the default. Cache-aside in front of your database (see Caching).
- Rate limiting —
INCRa per-user key with a TTL window; reject over the limit. - Leaderboards / top-K — a sorted set keeps items ranked by score with cheap range reads.
- Distributed locks —
SET key value NX EX 10grabs a lock that auto-expires so a crashed holder can't deadlock everyone. - Pub/Sub — broadcast a message to every subscriber; used to fan WebSocket messages across servers.
- Sessions — a shared session store so any stateless app server can authenticate any request.
What to watch
- It's memory. RAM is finite and pricier than disk — cache what's hot, set TTLs, and alert on memory.
- Eviction policy is a choice.
allkeys-lru(drop least-used) is right for a cache;noevictionis right for sessions and queues, where silently dropping data logs people out or loses jobs. Don't mix a cache and a session/queue store in one instance with one policy — split them. - Durability is optional. Redis can persist to disk, but it's primarily in-memory; treat it as fast, replaceable state and use managed Redis with replication/failover when it's critical infrastructure.
- One key, one node. A single hot key is served by one node — a sorted set that's enormous or a counter that's wildly hot can become a bottleneck.
What to say in an interview
Name the structure, not just "Redis":
"I'd put Redis in front of the database for the hot reads, and use the same Redis for rate limiting — an
INCRon a per-user key with a one-minute TTL. The leaderboard is a sorted set so I get ranked reads for free. I'd run a separate Redis for sessions withnoevictionso a memory-full cache can't log everyone out."
Next up: Elasticsearch — when you need real search, not LIKE.