The near-universal in-memory data store used for caching, sessions, and queues, prized for being extremely fast.
Why it exists
Some data needs to be read and written far faster than a normal database allows, sessions, counters, and caches, and it can live in memory. Redis exists as a fast in-memory data store used for exactly those hot, short-lived pieces of data.
How it actually works
Redis keeps data in memory rather than on disk, which makes it very fast but suited to data you can afford to lose or rebuild. That profile makes it perfect for three jobs at once: caching computed answers, holding session data all servers can share, and backing message queues.
When engineers say "put it in Redis," they usually mean cache it or store it somewhere fast and shared, rather than in the main database.
A senior PM walks you through it
A junior PM, stuck
We had a bug where customers' carts kept vanishing after we scaled to three servers, and the engineer said we will put it in Redis and closed the thread. I know Redis is fast storage, but I cannot tell what putting the session in Redis actually fixes, or why it is different from just using our normal database. I do not want to nod through the next one too.
Redis is one small, very fast store that every server can reach, and it does three jobs at once. The clearest way to see it is to open it. Below is a redis-cli session, the command-line window into that store, showing its whole keyspace and then each key inspected. One of those keys is the session, and it is exactly the thing that fixes your vanishing carts. Read these lines and put it in Redis stops being a shrug.
A redis-cli look inside TiffinBox's Redis store
the whole keyspace, three jobs in one store
1127.0.0.1:6379> SCAN 0 MATCH *
21) "cache:product:p_1042"
32) "session:u_88231"
43) "queue:order-sms"
the cache key: a computed answer that expires itself
Hearing Redis as just a faster database. It is memory-first and holds hot, short-lived data you can rebuild; treating it as the permanent home for orders or payments risks data you cannot afford to lose on a restart.
Forgetting the TTL on cached data. A cache key that lives 58 seconds means a price or stock change is invisible for up to that long; when customers see an old value just after an edit, an unexpired cache key is the usual reason.
Missing that the session's value is sharing, not speed. The vanishing-cart fix works because all servers read one session store; if you frame it only as Redis is fast you will miss when the real requirement is shared state.
Assuming put it in Redis is one thing. Caching, sessions, and queues behave differently; approving the phrase without asking which job leaves you unable to reason about staleness, sharing, or backlog later.
Next time, ask: "Put it in Redis for which job, cache, session, or queue." For the cart bug, the answer is session: moving it to Redis means all three servers read one login store instead of each keeping its own, so the cart stops vanishing. You read the keyspace and matched the job to the fix, which is the skill.
Where a PM meets this
It shows up as the answer to speed and sharing problems; recognizing the name keeps you oriented when it's mentioned.
"It's cached in Redis" implies fast but possibly slightly stale; the freshness trade-off from caching applies.
Hear it in a meeting
"Sessions and the hot product cache both live in Redis."