What is Caching?

A thousand visitors may ask for the same product description within a minute. If the application rebuilds the answer from the database each time, it repeats work. A cache keeps a reusable copy close to where it is needed.

Reading a useful cached copy can reduce database work and waiting time. The copy can also become stale when the original changes. A good design decides which information may be reused, for how long, and what happens when the cache is unavailable.

A cache hit means a usable entry is present. A miss means the application must fetch or rebuild the answer. In the common cache-aside approach, the application checks the cache, reads the database on a miss, and then stores a copy.

A cache key identifies the answer, such as product:tea. A key for private information must also separate the relevant user or access context. Reusing one person’s private response for someone else is a correctness and access-control failure.

Time to live, or TTL, is the period after which an entry expires. TTL can bound how long a copy is reused, but it does not make every read immediately reflect a new write. Choose a lifetime from the information’s freshness requirement, not just from the size of the cache.

Start with a product price of 10. The first read misses and loads the database value; the second can use the cached copy. Now change the database price to 12 without changing the cache. Predict what the next read returns.

Invalidate the entry—remove it—then read again. You can also simulate TTL expiry. Expiry here is a manual event, not a running clock. Database-read counts show calls in this browser model, not a production performance measurement.

Product descriptions and public summaries

A short TTL may be acceptable when a brief stale period does not harm the user. After an update, invalidation can make the next read rebuild the answer. Concurrent readers and writers can still race, so a real design needs a clear update order and, when needed, version checks.

Stock, permissions and final prices at checkout

A cached display may help browsing, but the purchase must validate critical facts against the authoritative store. Do not promise the last item or authorise an action from an old cached answer alone.

A cache usually holds data you can rebuild. Eviction removes entries to make room; an entry can disappear before its TTL. A restart or network failure can also make the cache unavailable. Treat misses and cache failures as expected paths, while controlling the extra work sent to the database.

If a popular entry expires at once, many callers can try to rebuild it together. This is often called a cache stampede. The database may receive a sudden surge even though average cache performance looked good.

Assume a teaching workload of 1,000 reads per second. At a 90% hit rate, 100 reads per second reach the database. If the cache becomes unavailable, up to all 1,000 may reach it under a naive fallback. These are illustrative read counts; latency and capacity need measurement.

Possible protections include allowing one rebuild while others wait, spreading expirations over time, serving an explicitly acceptable stale copy, and limiting or rejecting excess work. Each changes freshness, waiting time or availability. Pick protections from the application’s requirements.

Representative sources checked 6 October 2026. Measure item size, memory use, hit rate, eviction, response time and database load during failure; no cache product has one universal operations/s guarantee.

• Valkey is a BSD-licensed, in-memory data-structure store. It is a candidate when the application needs more than simple opaque values, such as collections and counters. Self-hosting includes capacity, updates and recovery work.
• Memcached is an open-source memory cache for reusable data. Evaluate it for simple key-value caching; applications must handle misses, invalidation and expired or evicted entries.
• Amazon ElastiCache offers managed cache deployment options, including Valkey and Memcached. Compare the selected engine, deployment mode, features and pricing, rather than assuming every option behaves identically.

Choose from the requirement

For simple reusable values, compare Memcached with Valkey using the team’s existing skills and the actual workload. For useful data structures or counters, evaluate Valkey’s supported commands and guarantees. If hosting is in AWS and operating time is limited, evaluate ElastiCache while budgeting ongoing charges. A managed cache still requires a freshness policy and safe application fallback.

Hardware and memory affect capacity, but a larger cache does not fix an incorrect key, private-data mix-up or a write that leaves an old copy in place.

Expiration limits how long a cached entry is usable. Eviction removes an entry to make room when memory is constrained, possibly before its expiry. A miss can therefore happen even if the original data has not changed.

Least recently used, or LRU, prioritizes entries that were accessed recently; least frequently used, or LFU, considers access frequency; FIFO removes older insertions first. Real implementations can approximate these policies and have product-specific details. The best policy depends on workload and entry size.

A cold cache starts with few useful entries; a warm cache has accumulated reusable answers. Plan database load during cold start, eviction and fleet restart. Coordinate or pace fills for popular keys, and bound memory rather than assuming a long TTL guarantees that every entry remains present. Read Redis eviction policies.

Use Cache-Aside to trace the miss path and write-through and write-behind to compare acknowledgement and persistence. Flyweight instead shares safe common object state; it is not a cache freshness policy.

Caching trades some repeated work for the responsibility of maintaining useful copies. Plan keys, expiry, invalidation and the information that must be checked against the authoritative store.

A hit rate is useful, but misses, eviction, races and cache failure decide whether the whole design remains dependable. Test those paths before relying on the cache to protect storage.