What does a missing in-memory key mean?

The shop caches product summaries in Redis. If a summary is absent, it reloads the product from the authoritative database. Losing that cached key makes a request slower, but the product still exists.

Later, the application stores its only record of a purchase reservation as another key in the same service. Now absence has a different meaning. Does it mean no reservation was made, the reservation expired, memory pressure removed it, or a restart lost it?

Follow two keys through memory pressure

Redis supports configurable eviction policies: when memory reaches the configured limit, some policies remove eligible keys to make space. Expiration is a separate rule that removes a key after its time limit. Neither mechanism knows that your application has started treating one key as its only evidence of a purchase.

Cached summary disappears

Read the authoritative product.
Rebuild the summary.

Only reservation record disappears

No independent record remains.
Absence cannot explain what happened.

The same missing-key response is recoverable for one role and ambiguous for the other.

Using a no-eviction policy changes the failure behavior: memory-growing writes can be rejected instead of evicting existing keys. The application must handle that rejection. It still needs to define restart and failover behavior, and must not attach an expiration time that contradicts the record’s required lifetime.

Separate fast access from durable acknowledgment

Memory access can remove a storage read from the common path. It does not establish what survives a crash. Redis offers snapshot and append-only-file persistence options, with different configuration choices and recovery implications.

Consider an illustrative periodic-snapshot-only setup. A snapshot captures state at 12:00. A reservation is accepted at 12:01. The process and its volatile memory are lost at 12:02, before another snapshot. Restoring only the 12:00 snapshot cannot reconstruct that reservation. Adding a replica changes the possibilities but still requires an acknowledgment and failover contract.

Capacity also includes more than value bytes. Suppose a hypothetical workload has one million values of 100 bytes. That is 100 MB of payload in decimal units. Keys, data structures, allocator overhead, buffers, and persistence work require additional memory. The payload calculation is a starting point, not a measured Redis capacity estimate.

Predict the safe cache miss

All product summaries disappear, but the authoritative product table is intact. Is serving a million simultaneous misses automatically safe?

Consider the reconstruction work

No. Correct reconstruction can still overload the source database. Limit concurrent fills, share work for the same missing key where appropriate, and admit requests within measured capacity. “Rebuildable” describes recoverability; it does not make rebuilding free or instantaneous.

Before choosing a memory-oriented design, specify whether each record is disposable, how it can be reconstructed, and what an acknowledged change must survive.

Sources: Redis key eviction and Redis persistence. Configuration determines the actual contract.

Extended reference

The extended chapter preserves the original technical coverage, additional examples, and citations. The explanation above supplies the concepts needed for this page; the reference develops the specialist cases.

Find a section from the original chapter