Redis
- Pradeep P
- 3 days ago
- 4 min read
Layer 1 · Post 10 of 15
Layer 1 — The building blocks · Post 10 of 88
Redis is an in-memory data store used as a cache, lock service, rate-limit counter, and short-lived state layer in front of slower databases.
What you'll learn
What Redis is good at (and why "in memory" is the point)
The data structures you actually use in system design
Durability, eviction, and when Redis is the wrong box
The idea in one minute
Redis is a server that keeps data in RAM and talks a simple protocol. Reads and writes are typically sub-millisecond on a healthy instance.
People call it a cache. That is the most common job. It is also used as:
A session store
A rate-limit counter
A distributed lock (with care)
A queue (lists or streams)
A pub/sub bus for "tell everyone this happened"
It is not a replacement for your primary database unless you really mean "we accept RAM + optional disk snapshot as the source of truth."
Why it matters
After you understand caching as an idea, you need a shared cache. In-process maps do not help when you have 20 API replicas. They each have a different map.
Redis (or Memcached) is the shared memory of the fleet. Almost every "design X" answer that includes a cache means something in this slot. Redis won because it is fast, simple to operate at small scale, and has useful types beyond "string in, string out."
How it works
Clients connect over TCP. Commands look like GET user:42, SET user:42 '{...}' EX 60, INCR rl:user:42:2026-08-31T20.
Because data lives in memory, capacity is RAM. When RAM is full, Redis evicts keys (if you configured a max memory policy) or starts failing writes. Eviction is why a cache can forget things you did not TTL.
Types you will draw in interviews
Type: String; Use: JSON blobs, counters, tokens
Type: Hash; Use: Object fields (HGET user:42 email)
Type: List; Use: Simple queues (push/pop)
Type: Set; Use: Unique membership, tags
Type: Sorted set; Use: Leaderboards, "next job by time"
Type: Stream; Use: More serious event logs / consumer groups
You do not need all of these on day one. Strings + TTL cover a large fraction of caches.
Persistence (optional, easy to misunderstand)
RDB: periodic snapshots to disk. Fast. You can lose minutes on crash.
AOF: append each write. Safer, more disk.
Neither: pure cache. Restart = empty. That is valid if the DB can refill.
If you store sessions only in Redis with no persistence, a Redis restart logs everyone out. Sometimes that is acceptable. Sometimes it is an incident.
High availability
A single Redis is a single point of failure. Production uses replicas (read scaling, failover) and often cluster mode (shard keys across nodes). Failover is not instant and is not magic — split-brain is a real ops topic. For this layer: do not put irreplaceable data only on one Redis process.
A simple example
Cache-aside for a user profile
GET user:42:profile
Miss → SELECT from Postgres → SET user:42:profile <json> EX 120
Hit → skip Postgres
Rate limit
INCR a key rl:42:minute with EXPIRE 60 if it was new. If the number is over 100, return 429. The counter lives in Redis so all API pods share the same count.
Lock (sketch)
SET lock:order:99 token NX EX 10 — only one worker processes that order. You must unlock safely (Lua / compare token). Locks in Redis are easy to get slightly wrong; the idea is "short-lived lease," not a database transaction.
Common mistakes
Huge values. 5 MB JSON per key will tank memory and network. Cache a small projection or use a different store.
Hot keys. One celebrity key on one cluster shard saturates a core. Replicate that key, split it, or cache it locally in the app with a tiny TTL.
KEYS * in production. It scans everything. Use SCAN. Better: know your key names.
Using Redis lists as your only job queue at huge scale. It works until it does not. Kafka and dedicated queues exist (Layer 2) for a reason.
Treating Redis as durable primary storage without a persistence and backup story you have actually tested.
How this shows up in real systems
Twitter, GitHub, Shopify, almost every SaaS: Redis or equivalent for sessions, rate limits, feature flags, hot keys.
Memcached: simpler, RAM-only cache, no rich types. Still the right tool when you only need blobs.
Managed offerings: ElastiCache, Memorystore, Redis Cloud — same idea, less babysitting.
When you say "we'll add Redis" in a design, say what key, what TTL, what happens on miss, and what happens if Redis is down (fail open vs fail closed).
Recap
Redis is shared, in-memory, very fast storage with useful data types.
Default role: cache and short-lived coordination, not the system of record.
Size it by RAM, plan eviction, and decide durability on purpose.
Caches sit in front of databases. Time to talk about the system of record itself.
Layer 1 · Post 10 of 15
Comments