What Is Caching and How Redis Works

1What Is Caching?

Caching is the practice of storing a copy of frequently used data in fast storage so that future requests can be served without redoing expensive work. Instead of querying a database or calling an API every time, the application checks the cache first and returns the saved result if it is there.

The idea is simple: computing something once and reusing the answer is far cheaper than computing it repeatedly. A cache turns a slow, repeated operation into a fast memory lookup.

2Why Caching Matters

Caching is one of the highest-leverage optimisations available because most workloads read the same popular data over and over. A small cache can absorb a large share of traffic.

• Lower latency: memory reads are orders of magnitude faster than disk or network calls.
• Reduced load: fewer queries hit your database, so it scales further on the same hardware.
• Lower cost: serving from cache is cheaper than provisioning bigger databases.
• Better resilience: a cache can keep serving popular data even if the source is briefly slow.

3How Redis Works

Redis is an in-memory key-value store, meaning it keeps its data in RAM rather than on disk, which is why reads and writes complete in well under a millisecond. You store values under keys and fetch them back by key, much like a giant dictionary shared across your whole application.

Redis is single-threaded for command execution, which keeps its behaviour predictable and avoids locking complexity. It can persist data to disk with snapshots or an append-only log, so a restart does not have to lose everything.

• SET user:42 "Ada" # store a value under a key
• GET user:42 # retrieve it
• SET session:abc "data" EX 3600 # expire after 3600 seconds
• INCR page:views # atomic counter
• LPUSH jobs "task1" # push onto a list used as a queue

4Common Caching Strategies

How and when data enters and leaves the cache is a design decision. A few patterns cover most needs.

• Cache-aside: the app checks the cache, and on a miss loads from the database and stores the result. Most common.
• Write-through: writes go to the cache and the database together, keeping them in sync at write time.
• Write-behind: writes hit the cache first and are flushed to the database asynchronously.
• TTL expiry: entries carry a time-to-live and are removed automatically when it lapses.

5Eviction and Consistency

Two hard problems define real-world caching: deciding what to remove when memory fills, and keeping cached data in step with the source of truth.

• LRU (least recently used): evict the item untouched the longest — a sensible default.
• LFU (least frequently used): evict the item requested the fewest times.
• TTL: let entries expire on a timer regardless of use.
• Invalidation: explicitly delete or update a cache entry when the underlying data changes.

6Redis Beyond Caching

Although caching is its most famous use, Redis is a versatile data structure server that solves several other problems well.

• Session storage: keep user sessions in Redis so any app server can serve any user.
• Rate limiting: atomic counters with expiry enforce request quotas.
• Queues: lists and streams act as lightweight job queues.
• Leaderboards: sorted sets rank items by score in real time.
• Pub/Sub: publish and subscribe to channels for real-time messaging.

7Caching Best Practices

A few habits keep a cache helpful rather than a source of subtle bugs.

• Always set a TTL so stale entries cannot live forever by accident.
• Cache the expensive-to-compute, frequently-read data first — measure before caching everything.
• Design a clear invalidation path for data that changes.
• Never treat the cache as the source of truth; it must be safe to lose.
• Monitor hit rate; a low hit rate means the cache is not earning its keep.

8Common Mistakes to Avoid

Most caching pain traces back to a handful of avoidable errors.

• Forgetting to invalidate, so users see outdated data after an update.
• Caching data with no TTL, letting memory fill with entries no one wants.
• Treating the cache as durable storage and losing data when it restarts.
• The thundering herd: many misses hit the database at once when a popular key expires.

9Key Takeaways

The essentials of caching and Redis come down to a few points.

• Caching stores hot data in fast storage so repeat reads skip expensive work.
• Redis is an in-memory key-value store serving reads and writes in sub-millisecond time.
• Cache-aside with a TTL is the most common and safest starting strategy.
• Eviction (LRU/LFU/TTL) and invalidation are the two hard problems to plan for.
• Redis also powers sessions, queues, counters, leaderboards, and pub/sub.

10Frequently Asked Questions

Q: Is Redis only used for caching? A: No. Caching is its most popular use, but Redis is a general data structure server used for session storage, rate limiting, job queues, leaderboards, and real-time pub/sub messaging.

Q: What happens if Redis runs out of memory? A: It applies your configured eviction policy — such as evicting least-recently-used keys — or rejects new writes if eviction is disabled. Always set a maxmemory limit and policy in production.

Q: How do I keep the cache consistent with my database? A: Invalidate or update the cache entry whenever the source data changes, and give entries a TTL as a safety net so any missed invalidation self-corrects when the timer expires.

Q: Does Redis lose data on restart? A: By default it holds data in memory, but you can enable persistence via snapshots (RDB) or an append-only file (AOF) so data survives restarts. Even so, treat a cache as replaceable rather than a primary store.