This appendix gathers the main terms used throughout the guide in one place. It is meant to work as a practical reference during design reviews, incident analysis, and architecture discussions, not just as a list of short definitions.
Use it when a caching conversation becomes fuzzy around terms like freshness, invalidation, coherence, stale serving, or scope. Many cache mistakes come from teams using the same words for different concepts.
flowchart TD
A["Cache terminology"] --> B["Reuse and identity"]
A --> C["Freshness and invalidation"]
A --> D["Load and resilience"]
A --> E["Distribution and scope"]
A --> F["Security and isolation"]
Reuse and Identity
- Cache
- A storage layer that keeps previously computed or fetched results so future requests can reuse them instead of repeating the original work.
- Cache key
- The identifier the cache uses to decide whether two requests should reuse the same stored value. If the key is incomplete, the cache may serve the wrong response.
- Cache value
- The stored payload associated with a key. Depending on the system, the value may be a full response, a database row, a rendered fragment, a computed summary, or a negative lookup result.
- Working set
- The subset of data that is actively reused often enough to benefit from staying in cache.
- Hot key
- A key that receives much more traffic than average. Hot keys create performance leverage when cached well and incident risk when they miss all at once.
- Hot set
- A broader collection of keys that receive disproportionate traffic over a period of time.
- Negative cache
- A cache entry representing absence or failure, such as “record not found,” usually with a short TTL to avoid repeated expensive misses.
- Memoization
- Reusing the output of a function or computation when the same inputs appear again.
Freshness and Invalidation
- Freshness
- How closely a cached answer reflects the current source of truth.
- Staleness
- The gap between the cached answer and the current source state. Some staleness is acceptable in many systems, but it must be deliberate.
- TTL (time to live)
- The amount of time a cached entry may remain eligible for reuse before it expires.
- Expiration
- The point at which the system treats a cached entry as no longer valid for ordinary reuse.
- Invalidation
- The act of marking cached data as no longer trustworthy after a change in source truth or policy.
- Purge
- An explicit invalidation action that removes one or more cache entries, often by key, prefix, or tag.
- Versioned key
- A key that includes a generation number, version token, or content hash so new data naturally maps to a new cache identity.
- Generational cache
- A cache design in which version changes shift readers to new keys rather than mutating existing keys in place.
- Tag-based invalidation
- A strategy that groups entries by labels so one purge can invalidate many related items.
- Dependency graph
- A representation of which cached artifacts depend on which lower-level objects, views, or aggregates.
- Read-after-write consistency
- The expectation that after a write is committed, a subsequent read reflects that write, especially for the writer.
- Stale-while-revalidate
- A pattern where the system may serve a stale value briefly while refreshing it in the background.
- Stale-if-error
- A pattern where the system serves a stale value when the fresh path fails or the origin is unhealthy.
Load and Resilience
- Hit
- A request served from cache without needing the original expensive source.
- Miss
- A request the cache cannot satisfy, so the system must fetch or recompute the value.
- Hit rate
- The share of requests served from the cache rather than the origin. Useful, but never sufficient by itself to judge cache quality.
- Origin
- The source of truth or expensive backend that the cache protects, such as a database, external API, or compute-heavy service.
- Cache-aside
- A pattern where the application checks the cache first and populates it after a miss.
- Read-through
- A pattern where the cache layer itself knows how to fetch data from the backing source on miss.
- Write-through
- A pattern where writes go through the cache and backing store together so the cache stays aligned with committed writes.
- Write-behind / write-back
- A pattern where the cache accepts writes first and propagates them to the backing store later. It can improve latency but increases durability and ordering risk.
- Dogpile
- A surge of concurrent recomputation caused by many requests missing the same key at roughly the same time.
- Cache stampede
- A broader term for the same kind of hot-key miss surge where several readers all try to rebuild the same value.
- Thundering herd
- A wider synchronized miss pattern involving many keys, nodes, or clients that creates cascading load on shared backends.
- Singleflight / request coalescing
- A technique that lets one request perform the refill while others wait for or reuse the same in-flight result.
- Jitter
- Intentional variation in TTL or refresh timing so many entries do not expire simultaneously.
Distribution and Scope
- Layered cache
- A cache design with more than one reuse layer, such as browser, CDN, reverse proxy, application, and shared distributed cache.
- Distributed cache
- A cache shared across several application instances or nodes.
- Coherence
- The degree to which several cache nodes or layers stay acceptably aligned after source changes.
- Propagation lag
- Delay between a source change and the moment other cache nodes learn about it.
- Regional cache
- A cache scoped to one geographic region or latency domain.
- Geo-aware caching
- A design that includes region, locale, jurisdiction, or similar geographic scope in cache placement or identity.
- Eviction
- Removal of entries because of capacity pressure rather than because of explicit invalidation.
- LRU (least recently used)
- An eviction policy that tends to keep recently accessed items.
- LFU (least frequently used)
- An eviction policy that tends to keep frequently accessed items.
- Working-set churn
- A condition where the cache repeatedly evicts items it will soon need again, usually because capacity or policy does not match the workload.
Security and Isolation
- Cache scope
- The set of actors allowed to reuse the same cached answer. Scope may be public, per-tenant, per-user, per-session, or even more specific.
- Authorization-aware caching
- Caching that reflects roles, permissions, or policy context instead of assuming that one allowed response is safe to share broadly.
- Data leakage
- Exposure of one user’s or tenant’s data to another because cache identity or scope was modeled incorrectly.
- Tenant isolation
- Protection against both direct data crossover and noisy-neighbor effects inside shared cache infrastructure.
- Retention
- How long cached data remains stored or reachable across layers. This matters especially for regulated or confidential data.
- Blast radius
- The scope of harm caused by a purge, cache failure, hot tenant, or recovery action.
Frequently Confused Distinctions
- Expiration vs invalidation
- Expiration is time-based. Invalidation is trust-based. An entry can be invalidated immediately even if its TTL has not expired.
- Miss vs stale serve
- A miss causes fallback to the origin or recomputation. A stale serve still uses cached data, but the system knowingly accepts bounded staleness.
- Eviction vs purge
- Eviction happens because capacity is limited. Purge happens because correctness or policy requires removal.
- Versioned key vs explicit delete
- Versioned keys change identity so readers move to new entries. Explicit deletes remove existing entries in place.
- Coherence vs consistency
- Coherence usually describes alignment among cache nodes or layers. Consistency is the broader correctness relationship between reads, writes, and source truth.
- Public cache vs shared cache
- A shared cache is any cache reused by multiple clients or instances. A public cache is specifically intended to serve content that is safe to share broadly.
How To Use This Appendix
If a cache design feels confusing, start by checking whether the team agrees on:
- what the key identity actually is
- what freshness promise is being made
- how invalidation differs from eviction
- what load behavior happens on miss
- what the sharing scope is from a security perspective
Most cache design arguments become clearer once those terms are anchored precisely.