Async & data line
Redis deep-dive
Leela checks a small shelf before she walks back to the storeroom.
Stops explain each step. The film plays the whole ride.
- Checking or copying
- Waiting or empty
- Written down
- Stale or slammed
Leela checks the shelf first
She looks on the shelf before walking back to the storeroom.
Next stop: The shelf does not have it
All stops
The everyday version
The shelf is a quick copy. The storeroom is the real record. A timer, a full shelf, a notebook, and a shout are the ways that copy can mislead you.
- Leelais the App
She checks the shelf, restocks it, and shouts toward the door.
- The shelfis the Redis
A copy in front. Fast to check, and wrong if nobody clears it.
- The storeroomis the Database
The real jar. Every miss walks here unless the shelf already has a copy.
- The notebookis the Disk
A photo, or a list of moves, so a restart is not a bare shelf.
- A listeneris the Subscriber
Hears the shout only if they are here when it happens.
- A kept shoutis a stream
History you can read later. This page's shout does not keep one.
Interview questions
Say the short answer first. Go deeper only if they ask.
What is cache-aside?
The app checks the cache, and on a miss loads the database and stores a copy.
The app owns that logic. Read-through and write-through hide it in the cache layer. Update the copy with a TTL or by deleting the key, or you serve stale data. A timer that ends for a hot key can also stampede the database.
“Redis automatically syncs with the database.”
How do snapshots differ from the write log?
A snapshot is a photo. The write log, once turned on, replays changes and can drop about one second.
Snapshots to dump.rdb are on by default. Redis forks a child to write the file, and a crash can lose the latest minutes. appendonly yes turns on the log. The default fsync is every second. Redis suggests both when you want safety closer to a database, and discourages the log alone. Since 7.0 the log is a base file, incremental files, and a manifest.
“Redis never writes to disk” or “a snapshot loses nothing.”
What happens when memory is full?
Open-source Redis defaults to noeviction, so writes that need memory fail.
On 64-bit builds maxmemory starts unset, so there is no cap. Once you set one, noeviction is the redis.conf default: reads still work, and writes that need memory return an error. allkeys-lru is the usual cache policy. Policies that only evict keys with a TTL behave like noeviction when no key has one. LRU and LFU sample keys rather than tracking a perfect order. Redis Software databases often default to volatile-lru instead.
“Redis always throws out the oldest key.”
How is a shout different from a stream?
A shout is gone after it is sent. A stream keeps history and can be acknowledged.
Pub/sub is at-most-once. A subscriber that is offline misses the message, and there is no ack. Streams append entries with ids. Consumer groups can read, acknowledge, and replay.
“Pub/sub guarantees delivery.”
Why is a key lookup fast, and what still blocks?
A plain key read is constant time, but one thread runs commands.
Redis serves commands on one thread, so KEYS walks the keyspace and everyone else waits. Use SCAN to walk in small steps. I/O threads can move socket reads and writes off that thread. They do not make a long command parallel. Replicas and Cluster are how you scale past one process.
“Use KEYS in production to list keys.”
Cheat-sheet
Commands you will actually type.
SET user:42 {"n":"Leela"} EX 300Store a copy that expires in 300 seconds.
CONFIG SET maxmemory-policy noevictionOpen-source default. Writes that need memory fail at the cap.
CONFIG SET maxmemory-policy allkeys-lruA cache policy. It samples keys. It is not an exact oldest-first list.
SCAN 0 MATCH user:* COUNT 100Walk keys in steps. Do not use KEYS for this on a live server.
PUBLISH news hiAt-most-once. Use XADD on a stream when you need the message later.