Explicit Delete and Purge Patterns

Explicit delete and purge patterns invalidate cache entries by naming what must stop being trusted now. Sometimes that means deleting one key after a write. Sometimes it means purging a whole set of related responses by tag, namespace, or surrogate key. This approach is appealing because it feels precise and immediate.

The challenge is scale and dependency reach. Explicit deletion works beautifully when the system knows exactly which entry changed. It becomes harder when one write affects many pages, many queries, or many edge nodes.

    flowchart LR
	    A["Source change"] --> B["Identify affected keys or tags"]
	    B --> C["Delete or purge"]
	    C --> D["Future reads refill or bypass"]

Why It Matters

This pattern matters because it is the most intuitive invalidation model for many developers. When a record is updated, remove the related cached value. When a page changes, purge the page. That directness is a strength. It also reveals whether the dependency model is actually clear enough to target the right cached artifacts.

Key Delete vs Group Purge

There are two broad forms:

• key delete: remove one known cache entry
• group purge: invalidate a set of related entries, often by namespace, tag, or surrogate key

Key delete is tighter and cheaper when the dependency is simple. Group purge is more realistic when one source change fans out to many derived artifacts.

Example

This policy shows direct key invalidation for entity caches and grouped purge for edge responses.

1purge_strategy:
2  product_entity:
3    on_update:
4      - delete_key: product:{product_id}
5
6  product_pages:
7    on_update:
8      - purge_tag: product-{product_id}
9      - purge_tag: category-footwear

What to notice:

• the entity cache can often be invalidated narrowly
• derived pages may need grouped purge instead of one key delete
• explicit invalidation is only as good as the dependency mapping behind it

Where Purge Patterns Break Down

This approach becomes fragile when:

• the system cannot reliably discover all affected artifacts
• purge fan-out is expensive or slow
• some layers support tags while others only support direct keys
• the architecture relies on too many manual or ad hoc invalidation calls

In those cases, explicit purge alone may be too brittle without TTL or event-driven backup.

Common Mistakes

• deleting only the obvious entity key and forgetting derived artifacts
• relying on URL-by-URL purge when grouped invalidation is needed
• assuming purge propagation across all cache layers is instantaneous
• embedding purge logic in many code paths without one clear dependency model

Design Review Question

Why is explicit delete often strongest for canonical entity caches but weaker for derived response caches?

The stronger answer is that entity caches usually map cleanly to one stable identity, while derived responses often fan out from many dependencies. The farther the cached artifact is from the canonical source, the less likely one direct delete is sufficient.

Quiz Time