# agent's optimization removed a cache that was load-bearing for a different endpoint nobody measured

## TL;DR

The cache looked unused because nobody measured its real consumers. Before removing any cache, map every reader: grep the codebase, check the cache key prefix in metrics, and watch hit rates during a canary with the cache disabled. A cache with zero measured readers is a guess, not a fact.

```text
agent's optimization removed a cache that was load-bearing for a different endpoint nobody measured
```

## Steps

1. Find every reader of the cache: search the codebase for the key prefix and check dashboards for hit-rate metrics by key pattern.
   Expected: You have the full reader list, including the surprise endpoint.

2. Check the surprise endpoint's latency with and without the cache (feature-flag the cache off for a canary slice).
   Expected: You measure the cache's real value to that endpoint.

3. Restore the cache and revert the removal.
   Expected: The endpoint's latency returns to baseline.

4. Before any future removal, require a reader map plus a canary with the cache disabled and hit-rate monitoring.
   Expected: Removals are proven safe instead of assumed safe.

5. Add cache-key-prefix dashboards so the next agent sees the readers without grepping.
   Expected: The dependency is visible in metrics, not just code.

## When to use

- removing a cache caused an unexpected regression
- a cache's readers are unknown
- an agent proposes deleting a cache

## When not to use

- the cache is provably unused (zero hits over a full cycle)
- the cache is being replaced, not removed (migrate readers explicitly)
- the regression came from something else in the same deploy (bisect first)

## Tool compatibility

- any caching layer (Redis, Memcached, in-process)
- feature-flagged canary workflow

## Variant phrasings

- "removed cache broke another endpoint"
- "cache was load-bearing for unmeasured endpoint"
- "agent deleted cache regression"

## Why it happens

Caches accumulate readers silently: a key written for endpoint A gets read by endpoint B six months later, and nothing records the dependency. Hit-rate dashboards aggregate by instance, not by reader, so the agent saw a healthy cache with no visible consumers and concluded it was safe to remove.

## Edge cases

- key-prefix metrics need the client to tag keys; untagged keys are invisible to this analysis
- a canary with the cache disabled on a hot path can cause a thundering herd; ramp the canary slowly
- TTL-only caches look removable right up until the thundering herd they were preventing

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_W32F36RNNuiEH6PozGTKTg