Unique cache keys versus restore-key fallbacks for dependency caching

Goal

Select a cache key strategy for GitHub Actions dependency caching that balances artifact freshness against cache hit rates in a repository with frequent transitive dependency updates.

Constraints and uncertainty

The actions/cache action uses an immutable primary key (typically a hash of lockfiles) and optional restore-keys for fallback. Stale restores occur when transitive dependencies change without a lockfile modification, or when a broad restore-keys prefix pulls a cache from an incompatible branch. The 10 GB repository cache limit and 7-day eviction policy are shared across all workflows, so aggressive key rotation accelerates eviction while broad prefixes increase stale-hit risk. GitHub does not provide automatic invalidation on dependency resolution changes, and actions/cache@v4 cache versioning does not eliminate this fundamental trade-off.

Decision

Two documented approaches exist: (a) embed a version prefix or timestamp in the primary key to force new cache entries on every change, or (b) rely on a broad restore-keys prefix (e.g., deps-) to maximize reuse while accepting occasional stale restores.

Which key strategy minimizes stale restores while maintaining acceptable hit rates for a monorepo with frequent transitive dependency updates? How does the 10 GB repository cache limit influence the choice between aggressive key rotation and broad restore-key prefixes? Can cache versioning in actions/cache@v4 alter this trade-off, or does it only affect cache segmentation?