How It Works Pricing Benchmarks
vs Redis Docs Resources Blog
Start Free Trial
New Primitive

Invalidate by Meaning.
Not by Pattern.

INVALIDATE WHERE intent='user pricing' CONFIDENCE 0.9 — the cache uses its built-in vector index to find all semantically related keys. No more KEYS user:123:* hoping you got the right pattern.

Intent-Based
Invalidation
Confidence
Threshold
Vector-Powered
VSEARCH Index
Zero
Over-Invalidation
The Problem

Pattern Invalidation Is String Matching

Every team that has ever typed KEYS user:123:* into a Redis console knows the feeling: did I get everything? Did I get too much? Pattern invalidation is a lexicographic operation applied to a semantic problem.

🔍
Patterns Miss What Matters
KEYS user:123:* finds user:123:profile but misses user:123:dashboard:v2 if the schema changed. It also misses pricing:tier:enterprise even though that key is semantically related to user 123's billing. String matching cannot understand relationships between concepts.
Misses keys with different naming conventions
📋
Invalidation Maps Are Brittle
Teams maintain hand-coded invalidation maps: “when pricing changes, invalidate these 47 keys.” Every schema change, every new feature, every renamed key breaks the map. The map lives in application code, scattered across services, impossible to verify without running the system. One missed entry means stale data in production.
One schema change = broken invalidation map
💥
The Nuclear Option
When pattern matching is too imprecise and invalidation maps are too fragile, teams resort to nuking entire prefixes. Flush everything matching user:123:*, accept the hit rate drop, recompute everything. This is safe but expensive — you are paying for cache misses on keys that were perfectly fresh because you could not tell them apart from the stale ones.
Over-invalidation = destroyed hit rate
How It Works

Embed the Intent. VSEARCH for Related Keys.

Every cache key gets a lightweight semantic embedding, computed at SET time or on first access. When you issue an INVALIDATE WHERE command, the cache embeds the intent query, searches the vector index for keys above the confidence threshold, and invalidates only those. The operator controls precision.

# Every key gets a semantic embedding at SET time SET user:123:price "49.99" # embedding auto-computed SET user:123:discount "15%" # embedding auto-computed SET user:123:billing:next "{...}" # embedding auto-computed SET user:123:avatar "img.png" # embedding auto-computed # Invalidate by meaning, not pattern INVALIDATE WHERE intent="user 123 pricing data" CONFIDENCE 0.9 # Matched and invalidated (>90% similarity): # user:123:price (0.97 similarity) # user:123:discount (0.94 similarity) # user:123:billing:next (0.92 similarity) # pricing:tier:enterprise (0.91 similarity) # NOT invalidated (<90% similarity): # user:123:avatar (0.31 similarity) # user:123:preferences (0.44 similarity)
Semantic Invalidation — Intent: “user 123 pricing data” @ CONFIDENCE 0.9
Invalidated (above threshold)
Matched
user:123:price
0.97 similarity
Matched
user:123:discount
0.94 similarity
Matched
user:123:billing:next
0.92 similarity
Matched
pricing:tier:enterprise
0.91 similarity
Not invalidated (below threshold)
Skipped
user:123:avatar
0.31 similarity
Skipped
user:123:preferences
0.44 similarity
Precision Control
CONFIDENCE 0.95 = surgical  |  CONFIDENCE 0.7 = broad
The operator controls the precision-recall tradeoff per command. No black-box decisions.

Embeddings at SET Time

Every cache key receives a lightweight semantic embedding when it is written. The embedding is computed asynchronously after the SET completes, adding zero latency to the write path. Key names, value schemas, and optional metadata are all factored into the embedding. The result is stored in the same HNSW vector index that powers Cachee's VSEARCH command.

For keys that already exist (migration scenarios), embeddings are computed lazily on first access. The vector index builds incrementally, with no bulk reindexing required.

The Confidence API

The CONFIDENCE parameter is the operator's precision dial. High confidence (0.95) means only keys with very strong semantic similarity are invalidated — safe for production, surgical, minimal blast radius. Lower confidence (0.7) casts a wider net, useful for development, debugging, or broad category invalidation like “anything related to billing.”

Every INVALIDATE WHERE command returns the list of matched keys and their similarity scores, so you can audit exactly what was invalidated and tune the threshold. There is no opaque AI making decisions — you see every score, every match, every skip.

Comparison

Five Ways to Invalidate. Each Has a Place.

Semantic invalidation fills the gap between “I know the exact key” and “I need to invalidate a concept.” Every method has a use case. The right tool depends on what you know at invalidation time.

Method Command Best When Weakness
Exact Key DEL user:123:profile You know the exact key name Only one key at a time
Pattern KEYS user:123:* / SCAN Keys share a predictable prefix Misses differently-named related keys; O(N) scan
CDC Automatic (DB trigger) Cache keys map directly to DB rows Does not handle key-to-key relationships
Dependency Graph DEPENDS_ON (DAG cascade) Known, explicit key-to-key dependencies Requires declaring dependencies at write time
Semantic INVALIDATE WHERE intent=... You know what changed conceptually but not which keys Requires vector index; confidence tuning
Composition

Composes With Everything

Semantic invalidation is not a standalone feature. It multiplies the power of every other Cachee primitive, creating invalidation strategies that no other system can replicate.

🔗
Semantic + Dependency Graph
Semantically invalidate a source key, and the dependency graph cascades the invalidation through the DAG. INVALIDATE WHERE intent="billing changes" finds the source key billing:plan:enterprise, and the graph automatically cascades to every dashboard, report, and composite that depends on it.
Semantic match → full DAG cascade
Semantic + Triggers
Cachee's ON_INVALIDATE trigger fires for every key that is semantically matched and invalidated. You can log the full list of matched keys with their similarity scores, emit metrics, or trigger downstream workflows — all from a single intent-based invalidation command. Full observability over what semantic invalidation does.
ON_INVALIDATE fires for every semantic match
💾
Semantic + CDC
CDC handles the database-to-cache mapping. Semantic invalidation handles the cases CDC cannot reach — keys that are related by meaning but not by direct table mapping. A row change in the pricing table triggers CDC for the base key, and a semantic rule catches every pricing-related key across every naming convention.
CDC + semantic = total coverage

Learn more about causal dependency graphs, CDC auto-invalidation, and cross-service coherence.

Pattern invalidation is string matching.
Semantic invalidation understands what you mean.
FAQ

Frequently Asked Questions

What is semantic cache invalidation?

Semantic cache invalidation uses vector embeddings to find and invalidate cache keys by meaning rather than by string pattern. Instead of running KEYS user:123:* and hoping the pattern matches all relevant keys, you issue INVALIDATE WHERE intent='user 123 pricing data' CONFIDENCE 0.9 and the cache uses its built-in vector index to find every key whose semantic embedding exceeds the 90% similarity threshold. This eliminates both over-invalidation and under-invalidation.

How does the confidence threshold work?

The CONFIDENCE parameter controls the precision-recall tradeoff. A high threshold like 0.95 means only keys with greater than 95% semantic similarity are invalidated — surgical, safe for production. A lower threshold like 0.7 casts a wider net, catching tangentially related keys — useful for development or broad category invalidation. The operator controls the threshold per command. Every command returns the matched keys with their similarity scores for full auditability.

Does semantic invalidation add latency to writes?

Semantic embeddings are computed asynchronously after the SET completes, adding zero latency to the write path. The embedding is stored in the same HNSW vector index that powers Cachee's VSEARCH command. Read-path GET operations are completely unaffected. The only latency cost is on the invalidation path itself — the VSEARCH query that finds semantically related keys — which completes in sub-millisecond time for typical cache sizes.

Can I combine semantic invalidation with CDC?

Yes. CDC auto-invalidation and semantic invalidation compose naturally. CDC watches your database change stream and invalidates base cache keys when rows change. Semantic invalidation handles the keys that CDC cannot reach — keys that are semantically related to the changed data but not directly mapped to a database table. Together, CDC covers the database-to-cache mapping and semantic covers the concept-to-cache mapping.

Is semantic invalidation safe for production?

Yes, when used with appropriate confidence thresholds. A CONFIDENCE of 0.9 or higher provides surgical invalidation that only touches keys with strong semantic similarity. There is no black-box AI making decisions — you see every similarity score, every match, every skip. For critical production paths, use CONFIDENCE 0.95 for maximum precision. The vector index uses the same battle-tested HNSW implementation that powers Cachee's VSEARCH command.

Stop Guessing Which Keys to Invalidate.
Tell the Cache What Changed. It Finds the Rest.

One INVALIDATE WHERE command replaces pattern matching, invalidation maps, and nuclear prefix flushes. Describe the intent. Set your confidence. Ship.

Start Free Trial Schedule Demo