RedisIntermediate

14 / Redis

Redis.

An in-memory data store that makes your application insanely fast

Every request touches the database. Reads, writes, joins — all of it hits disk. When traffic spikes, the database is the bottleneck. Redis sits in front — an in-memory cache that serves data in under a millisecond. It doesn't replace your database. It protects it.

In-memory speedSub-millisecond reads and writes — no disk I/O for cache hits

Rich data structuresStrings, hashes, lists, sets, sorted sets — not just key-value

Built-in Pub/SubLightweight message broker so services can broadcast without a queue

CacheData-structuresIn-memory

Intermediate+75 XP

Complete all 5 modules to earn +75 XP

The Speed Gap

How It WorksSINGLE THREAD

1 / 3

The Event Loop

Redis runs on a single thread. No locks, no race conditions.

Most databases use multiple threads and need locks to prevent data corruption when two threads write at once. Redis does not. A single event loop processes every command one at a time. No thread can interrupt another. No mutex needed. This is why Redis can serve millions of operations per second on a single core.

← → arrow keys or tap buttons to navigate

CH.1Write-Delete Pattern— Why you delete the cache, not update it

The Wrong Way — Update Cache DirectlyTwo users update the same record simultaneously. App A reads the DB, gets value X, writes X to cache. App B reads the DB a millisecond later, gets value Y, writes Y to cache. But App A finishes its write last — now the cache has X and the DB has Y. They are permanently out of sync. This is a race condition caused by writing to the cache directly.

The Right Way — Delete on WriteWhen data changes, write to the database and delete the cache key. Do not update the cache with the new value. The next read will miss the cache, fetch the fresh value from the database, and repopulate the cache cleanly. No race condition possible because only one process writes to the DB at a time.

Why Delete Beats UpdateDeleting is idempotent — deleting a key that is already deleted does nothing. Updating creates a race window where two writers can interleave. The delete pattern guarantees consistency because the next read always gets the latest DB state. It is the simplest safe caching strategy.

CH.2Cache Stampede— When a popular key expires and everyone hits the database

The Thundering HerdA popular product page is cached with a 60-second TTL. The key expires. Suddenly, 500 requests come in simultaneously — all miss the cache, all hit the database at once. The database spikes to 100% CPU, queries slow down, and cascading failures begin.

Why It HappensThe cache does not coordinate. Each request independently checks the cache, gets nothing, and goes to the database. They arrive in the same second because they were all triggered by the same user action or the same TTL boundary.

The Fix — Mutex + Early ExpirationOption 1: a mutex lock around the cache miss — only one request queries the database, others wait for it. Option 2: probabilistic early expiration — regenerate the cache before it expires based on access patterns. Option 3: set a longer TTL and refresh on read.

CH.3TTL Mental Model— Every cached key has a shelf life

Born With a TimerEvery key you SET into Redis with EX (expiry) has a built-in countdown. The timer starts the moment the key is created. Redis tracks it in memory and checks expired keys periodically. When the timer hits zero, the key is evicted — it stops existing, like it was never there.

Why TTL ExistsWithout TTL, stale data lives forever in the cache. The database could change and Redis would never know. TTL guarantees that even if you forget to invalidate, the cache will eventually clear itself. It is a safety net against stale data, not a replacement for proper invalidation.

Choosing the Right TTLShort TTL (60s) for volatile data like trending topics — ensures freshness. Long TTL (3600s) for stable data like product descriptions — reduces database load. No TTL for reference data that never changes. Every second of TTL is a tradeoff between cache hit rate and data freshness.

CH.4High Availability— Sentinel, Cluster, replication

Redis SentinelSentinel provides automatic failover. A sentinel process monitors the Redis master. If the master goes down, Sentinel promotes a replica to master and updates the configuration. Clients discover the new master via Sentinel queries.

Redis ClusterCluster shards data across multiple nodes. Each node owns a subset of keys (hash slots). If a node fails, its replicas take over. Cluster also handles resharding — moving hash slots between nodes without downtime.

Replication LagReplicas are asynchronous. A write to the master propagates to replicas eventually. If the master fails before a replica receives the write, that write is lost. Trade durability for performance — same as every distributed system.

CH.5Data Structures— Five types that cover almost every use case

Strings — The FoundationThe simplest Redis type. A key maps to a single value — a string, a number, a JSON blob, or even binary data. Strings are the backbone of caching (cache-aside), session storage, and counters. The SET/GET commands you already know handle strings.

Hashes — Objects Made EasyA hash maps field names to values inside a single key. Think of it as a Redis object — one key for "user:123" with fields "name", "email", "avatar". No need to serialize the whole object or fetch fields you do not need. Hashes are the most memory-efficient way to store structured data.

Lists, Sets, Sorted Sets — CollectionsLists are ordered sequences — great for message queues and timelines. Sets are unordered unique collections — perfect for tracking likes, readers, or tags. Sorted sets are sets with a score — every member has a number, and Redis keeps them sorted. This is how leaderboards, trending feeds, and rate limiters work.

Try ItProduction Lab

0 / 4 fixed

EVENT LOG

Incident opened: Product API is degrading under traffic.

P99 latency at 320ms — database CPU at 95%.

MISSION 1

Stop hammering the database

Every product page request hits PostgreSQL directly. 500 req/s, DB at 95% CPU, P99 latency is 320ms. The database is the bottleneck.

P99 Latency320ms

DB load95%

Cache hit rate0%

Memory usage22%

REQUEST EXPERIENCE

GET /products/featuredslow

GET /inventory/shoesslow

GET /products/trendingslow

GET /products/liveerror

🧠Quiz

1/10

●Concept

Where does Redis store data by default?

← Concepts←