What is Cache?

A cache is a high-speed data storage layer that stores a subset of data, so that future requests for that data are served much faster than fetching it from its primary source. As developers, we use caching to avoid repeating expensive database queries, heavy API calls, or complex computations. By trading a little bit of storage space, we drastically reduce latency and save our backend from unnecessary load.

How Caching Actually Works

The mechanics of a cache come down to two primary outcomes: a hit or a miss.

• Cache Hit: The requested data is found in the cache. The application returns it immediately, bypassing the slower database entirely.
• Cache Miss: The requested data is not in the cache. The application must fetch it from the primary storage.

In a standard read-through caching strategy, the lifecycle of a request follows a predictable path. First, the application checks the cache for the required data. If it results in a cache hit, the data goes straight to the user. If it results in a cache miss, the application pulls the data from the database, writes a copy into the cache for next time, and then returns the data to the user.

Core Caching Patterns

How you read and write data to your cache matters just as much as having one. There are three main patterns developers use:

• Cache-Aside (Lazy Loading): The application is in charge. It checks the cache. If the data isn’t there, the application queries the database, puts the result in the cache, and returns it. This is the most common pattern.
• Write-Through: The application writes data directly to the cache, and the cache immediately writes it to the database synchronously. It ensures the cache is always perfectly up-to-date, but it makes write operations slower.
• Write-Behind (Write-Back): The application writes data to the cache, and the cache acknowledges the write immediately. The cache then asynchronously updates the database in the background. It is blazing fast for writes, but carries a risk of data loss if the cache crashes before syncing.

The Developer’s Caching Stack

Caching happens at multiple layers of the technical stack. Here is where it usually lives:

• Client/Browser Cache: Lives on the user’s device. It uses HTTP headers like Cache-Control to set expiration rules and ETag tokens to validate if an asset has changed.
• CDN/Edge Cache: Systems like Cloudflare or Fastly that sit geographically closer to your users. They cache static assets like images, CSS, and JS files so your main server doesn’t have to handle the traffic.
• Application/In-Memory Cache: Tools like Redis or Memcached that sit in front of your database. They store data directly in RAM, making them incredibly fast for saving database query results or session states.
• CPU/Hardware Cache: The L1, L2, and L3 caches built directly into the computer processor. This is the hardware origin of the concept, designed to bridge the speed gap between the CPU and system RAM.

Cache Invalidation

Phil Karlton famously said, “There are only two hard things in Computer Science: cache invalidation and naming things.” The challenge is keeping your cache synchronized with your primary database. If data changes in the database but the cache isn’t updated, your users see stale, incorrect information.

Get Suleyman Mustafaev’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

To manage this, we use strategies like TTL (Time to Live), which sets an explicit expiration date on cached data. We also rely on eviction policies like LRU (Least Recently Used), which automatically deletes the oldest, least-accessed data when the cache runs out of memory.

Cache Stampede

When caching goes wrong under heavy traffic, it usually results in a cache stampede (also called the dogpile effect).

Imagine you have an expensive query that takes 3 seconds to run, and its cached result expires at exactly 12:00:00. At 12:00:01, 500 different users request that data.

Because the cache is empty, all 500 requests get a cache miss simultaneously. All 500 requests then bypass the cache and hit your database at the exact same time, asking it to run that expensive 3-second query. Your database gets overwhelmed and crashes.

Developers prevent this using techniques like locking (only letting the first request query the database while others wait) or probabilistic early expiration (refreshing the cache slightly before it actually expires).

Redis vs. Memcached

If you are setting up an application-level cache, you will almost certainly choose between these two in-memory datastores.

Redis vs Memcached

For modern applications, Redis has largely become the industry standard because of its flexibility, though Memcached is still heavily used when you just need raw, multithreaded string caching.

FAQ

What is the difference between caching and a database?
A database is designed for durable, long-term storage and complex querying of data to disk. A cache is a temporary storage layer, usually held in RAM, optimized strictly for speed rather than permanent persistence.

When should I NOT use a cache?
Do not use a cache for rapidly changing, critical real-time data, like stock balances or bank account ledgers, where seeing stale data causes immediate errors. Caching adds architectural complexity, so avoid it until performance metrics show that you actually need it.

Summary

Caching is ultimately a trade-off where you exchange memory space and architectural complexity for raw application speed. Used correctly, it is one of the most effective tools in your toolkit to scale an application.