I've kept Redis in front of production traffic — session stores, API response caches, leaderboards — for the better part of a decade, and it remains the first tool I reach for when a database starts feeling slow. Not because Redis is magic, but because it solves the one problem nearly every growing application has: the same small set of data being fetched from disk thousands of times a second.
Here's how Redis caching actually works, what it's good at, and — just as important — when you shouldn't use it.
Quick answer: Redis is an in-memory data store, so reading from it takes microseconds instead of the milliseconds a disk-based database needs. You use it as a cache by keeping frequently requested data in RAM under a key, with a TTL so it expires, and refreshing it from your database on a cache miss. Result: faster responses and a much lighter load on your primary database.
What Redis is (and its 2026 licensing situation)
Redis (Remote Dictionary Server) is an open-source, in-memory data structure store created by Salvatore Sanfilippo. It's most famous as a cache, but the same engine serves as a message broker, a session store, a rate limiter's backbone, and a real-time analytics layer.
One thing worth knowing in 2026: Redis has been through a licensing rollercoaster. In March 2024 it dropped its BSD license, the community forked it into Valkey under the Linux Foundation (AWS and Google back it), and then in May 2025 Redis 8 returned to an OSI-approved open-source license (AGPLv3, alongside the RSALv2/SSPLv1 options). Both projects are alive and wire-compatible with the commands below — nothing in this guide changes if you pick either.
How caching works: the cache-aside pattern
Redis caching in one loop:
1. Your application asks Redis for data under a key, say `user:42:profile`.
2. Cache hit: the data is in memory, so Redis returns it in microseconds. Done — the database never hears about it.
3. Cache miss: the key isn't there (first request, or it expired), so the application fetches from the database, returns the result, and writes a copy into Redis with a TTL (time-to-live) for next time.
That's the cache-aside pattern, and it covers 90% of real-world use. The TTL keeps data from going stale forever, and most frameworks — Spring Cache, Django, Laravel, Rails — implement this loop for you through a couple of lines of configuration.
What Redis does differently under the hood
Three design choices explain Redis's speed:
- Everything lives in RAM. Reading memory is orders of magnitude faster than even SSD-backed storage. A typical Redis get completes in under a millisecond; a database query that touches several tables rarely does.
- Data is organized, not just stored. Beyond plain strings, Redis has lists, sets, hashes, and sorted sets — so you can cache a top-10 leaderboard as a sorted set and update scores in O(log n), instead of re-querying the database with an ORDER BY on every request.
- Expiration and eviction are built in. Every key can carry a TTL, and when memory fills up you choose an eviction policy — for example `allkeys-lru` (drop the least recently used keys) or `volatile-ttl` (drop soon-to-expire keys first). The cache maintains itself.
Invalidation is the remaining piece: when the underlying data changes — a user edits their profile — you delete the affected key (or publish a change event via Redis Pub/Sub so every app server clears its view). Expiration handles staleness on a timer; explicit invalidation handles correctness the moment data changes. If you need the steps, CyberPanel has a practical walkthrough for clearing a Redis cache.
Why use Redis as your cache
1. Speed users can feel. Sub-millisecond reads turn a 400 ms page into a 60 ms page when most of that page is repeated data — product catalogs, config, user sessions.
2. A much lighter database. Every hit Redis serves is a query your database doesn't run. In the setups I've worked on, a well-tuned cache routinely absorbs 90%+ of reads, which delays expensive database upgrades by years, not months.
3. Real-time-friendly data structures. Sorted sets make leaderboards trivial, streams handle event feeds, and hashes map neatly onto cached objects — Redis caches shape, not just blobs.
4. It scales with you. Redis Cluster shards keys across nodes, and read replicas spread read load — which is also why a shared Redis layer is the standard caching move in a microservices architecture, where several services need to see the same cached data without hammering the database.
5. It's survivable. Optional persistence (RDB snapshots and AOF logs) means a restart doesn't have to mean an empty cache and a thundering herd against your database.
A 60-second example
With a Redis client for your language — PHP, Python, Node and friends all have first-class ones — the cache-aside loop looks like this from the CLI:
“`
SET user:42:profile "…" EX 300 # cache for 5 minutes
GET user:42:profile # cache hit
TTL user:42:profile # seconds remaining
DEL user:42:profile # invalidate after a data change
“`
When Redis is the wrong cache
Honesty section, because it saves people money:
- Your cached dataset is bigger than your RAM budget. Redis stores everything in memory; caching 200 GB of product images in RAM costs more than the disk reads you're avoiding. Cache pointers and hot data, not the ocean.
- You need strict read-after-write consistency everywhere. A cache is eventually consistent by nature. If users must see their own writes instantly across devices, design invalidation carefully or skip caching that data.
- The content is static HTTP. A CDN or Varnish at the edge will beat an application-level cache and costs less.
- The workload is genuinely simple. If you just need a plain key-value cache with no data structures, persistence, or pub/sub, Memcached is still a perfectly good, simpler choice.
FAQ
Is Redis still open source in 2026?
Yes. After the 2024 license change caused an uproar, Redis 8 (May 2025) added AGPLv3 — an OSI-approved open-source license — alongside RSALv2 and SSPLv1, so you can use Redis under a true open-source license again. The community fork Valkey, run by the Linux Foundation, is the BSD-licensed alternative if you prefer it, and it speaks the same protocol.
Does Redis lose all cached data when it restarts?
By default, yes — it's an in-memory store. But Redis offers two persistence options: RDB snapshots (periodic point-in-time saves) and AOF (an append-only log of every write). With persistence enabled, a restarted Redis repopulates itself and your cache warms up nearly full instead of cold.
What TTL should I use for cached data?
Start from how stale the data may be before it hurts: dashboards might live 30–60 seconds, product pages a few minutes, a homepage hero an hour. A few minutes with proper invalidation on writes covers most cases. Avoid one-week TTLs on anything that changes — that's how users see other people's data.
What is a cache stampede and how do I prevent one?
When a hot key expires, hundreds of requests can miss simultaneously and all hit the database at once. Prevent it by refreshing hot keys before they expire (a background job), using locks so only one request rebuilds the value, or letting stale values serve while one request updates — many Redis clients have this "single flight" behavior built in.
Redis or Memcached for caching?
Memcached is simpler and fine for plain string caching when one machine's RAM suffices. Redis wins once you want data structures, persistence, pub/sub, Lua scripting, replication, or cluster scaling — which is most real projects. Rule of thumb: start with Redis; reach for Memcached only when its minimalism is exactly what you need.
Can I use Redis as a primary database instead of a cache?
You can — with persistence enabled, many projects do — but it's a bigger commitment: your working dataset must fit (or shard across) RAM, and you inherit responsibility for durability planning. For most teams the sweet spot is Redis as the fast layer in front of Postgres/MySQL, which is exactly what this article describes.
Related reading
—
I've tuned Redis caches for e-commerce launches and API backends for years — if your hit rate is low or your TTLs feel wrong, describe the workload in the comments and I'll take a look.
