Redis basics: what it's for and when to use it
Quick answer
Redis is an in-memory data store. Because everything it holds lives in RAM rather than on disk, reads and writes are extremely fast, which is why it's used for caching, session storage, and lightweight message queues. That same speed comes from a trade-off: data in memory is more fragile than data on disk unless you deliberately configure persistence.
What Redis actually is
Redis stores data as key-value pairs in memory, with support for a handful of useful structures beyond plain strings: lists, sets, sorted sets, hashes, and a simple publish/subscribe mechanism. It's usually run as a separate service that your application talks to over the network or a local socket, similar in shape to how you'd talk to a database, but with a much smaller, faster operation set.
The three common uses
Caching
The most common use. If a database query or a calculation is expensive to run but its result doesn't change often, store the result in Redis with an expiry time. The next request for the same data reads it straight from memory instead of hitting the database again, which is both faster for the user and lighter load on the database.
Session storage
Web applications need somewhere to keep session data, such as who's logged in. That's trivial with a single application server, sessions can just live in that server's local memory. It stops being trivial the moment you run more than one application server, because a user's next request might land on a different server that has never seen their session. Redis solves this by giving every application server a shared, fast place to read and write session data.
Simple message queues
Redis's list and pub/sub commands are commonly used to pass small tasks or messages between services, for example queuing a job for a background worker to pick up. It's not a dedicated message broker, but for straightforward queueing needs it avoids introducing a heavier piece of infrastructure.
The trade-off: speed versus durability
Redis is fast largely because it doesn't have to touch a disk on every operation. That's also its main limitation as a primary system of record. If the Redis process stops without any persistence configured, everything it was holding is gone.
Redis does offer persistence options, and it's worth understanding what each one actually protects:
| Option | What it does | Trade-off |
|---|---|---|
| RDB snapshotting | Periodically writes a point-in-time snapshot of the whole dataset to disk | Fast and compact, but anything written since the last snapshot is lost on a crash |
| AOF (append-only file) | Logs every write operation to disk as it happens | Much better durability, but more disk I/O and a larger file to replay on restart |
Both can be combined, and both can be tuned for how often they sync to disk. The point isn't that Redis is unsafe, it's that durability isn't the default behaviour you get for free, it's something you configure deliberately once you understand what you're trading away. If a workload genuinely needs guaranteed durability as its primary concern, that's a reason to lean on a disk-backed database for the data that must never be lost, and use Redis for the parts of the system where speed matters more than permanence.