Caching, explained
How caches reuse work, where Redis fits, memory versus disk trade-offs, and how to keep saved copies aligned with the database.
A cache is a place to keep data you expect to use again. The saved copy can avoid another download, database read or calculation. That can make a repeat request quicker and reduce work for the system serving it.
A miss takes the longer route
Imagine a shop app fetching the details of a pair of trainers. It first looks for a usable saved copy. If none is available, the app reads the database, puts a copy in the cache and replies. This is a cache miss. When the next request finds a usable copy, it is a cache hit and can skip that database read. This particular approach is called cache-aside.
Different places keep different copies
Your browser can keep downloaded images and files on your device. A content delivery network, or CDN, keeps copies on servers near visitors. An application cache can keep the result of a calculation or data lookup. These layers save different kinds of work, and their rules need to suit the content.
Memory, disk and Redis
An in-memory cache keeps its working data in RAM, the computer's fast working memory. It suits frequently reused results because access is fast. The trade-off is costlier capacity, and data can disappear if the process or machine restarts unless it has been saved elsewhere.
A disk-backed cache stores cached data as files, on a solid-state drive or other disk storage. It usually offers more capacity for the cost, and the files can survive a restart. Reading storage is generally slower than accessing RAM. A cache on temporary storage can still disappear, so disk-backed does not mean permanent or backed up. NGINX, web-server software, is one example that can cache web responses on disk.
Redis is an in-memory data store often used as a shared cache. Several copies of an app can consult the same Redis service instead of each keeping an independent local copy. There is a network trip and another service to run, but a shared cache avoids maintaining separate cached answers inside every app instance.
Memory versus disk describes where data is stored. Local versus shared describes who can use it. A Redis server can be outside the app and still hold its data in memory. “Disk-backed” is the clearer term for storage outside RAM; “out of memory” usually describes a memory shortage.
Redis can also save snapshots or a log of writes to disk so data can be restored after a restart. These are persistence options. Saving Redis data does not automatically synchronise it with a separate database. A saved cache can preserve an old answer just as successfully as a current one.
Decide when the copy is too old
Our illustrative shop changes a price from £60 to £55. The database knows the new price, but an unchanged cached copy still says £60. Returning the copy quickly does not make it current.
- Expiry sets a lifetime for a cached item. TTL means time to live. A shorter lifetime offers fewer chances to reuse the copy.
- Invalidation marks a copy unusable or removes it when the source changes. Updating the database alone does not refresh every cached copy.
- A web cache can also revalidate, asking the source whether a stored copy is still current. It may then reuse unchanged content without downloading it again.
Expiry is not a promise that the source has stayed unchanged until that moment. We would check current price and available stock when accepting an order, even if the product page uses cached data.
Make source changes reach the cache
For the cache-aside pattern in our graphic, first commit the change to the authoritative database. Then invalidate the matching cached entry, making it unusable or removing it. The next read fetches the current value and caches it. Clearing the cache before saving the database change could let a reader immediately refill it with the old value.
This order is a useful starting point, not a guarantee of strict consistency. An invalidation request can fail. A read started before the update can finish afterwards and put old data back. A change made through another tool can miss the cache-clearing step entirely.
Record source changes reliably, retry failed invalidations and monitor the delay between a change and its cached copies being cleared. A change feed is a stream of updates from the database that can help connect every write path to the cache. Use expiry as a backstop, and test overlapping reads and writes rather than only a simple one-at-a-time example.
Where stronger guarantees are needed, the design can use version numbers to reject late, older updates, or coordinate updates through one controlled path. The exact protocol matters. A generic promise to “sync Redis” is not enough. For accepting an order, check stock and price in the authoritative system as part of the transaction, the operation that commits the order together.
Keep private answers private
A public product image can be shared across visitors. An account page belongs to a particular user. Web responses can carry rules that permit only a private browser cache, or prohibit storage altogether. A shared cache must never hand one person another person's account information.
Measure the benefit
For an illustrative calculation, suppose eight of ten reads use a cache. The hit rate is 80%, and two reads reach the database. That does not establish an 80% reduction in response time. Measure actual response times, slower misses and source load as well as hit rate.
Space also matters. A cache may evict entries, removing them to make room. For example, a policy can favour keeping items used recently. The app still needs to handle a miss correctly.
For the wider journey from an idea to a working service, see our prototype-to-production guide. Our website services cover building and maintaining the pages people use.