Q: Your Java/Gradle and Node/NPM pipelines re-download gigabytes of dependencies on every pull request, taking 18 minutes to compile and exhausting GitHub Actions runner disk space. Naive caching with actions/cache frequently results in cache misses or corrupted dependency caches. How do you design an optimal, multi-tier caching architecture with restore-keys and lockfile hashing?

Ensure cache hits are accurate and invalidate precisely when dependencies change:

• Cache Key Hash: Defined primary key: key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}.
• Deterministic Invalidation: If a developer adds or updates a single dependency, the hash changes, generating a pristine new cache entry without cache poisoning.

Prevent complete cache misses when lockfiles change:

• Restore Keys Stanza: Configured fallback keys: restore-keys: | ${{ runner.os }}-gradle-${{ hashFiles('gradle/libs.versions.toml') }} ${{ runner.os }}-gradle-.
• Partial Cache Re-Use: If the primary key misses, GitHub Actions restores the closest partial cache; Gradle downloads only the single newly added library (taking 5 seconds) rather than all 800 dependencies (taking 8 minutes).

Stop transient build outputs from bloating cache archives:

• Targeted Paths: Cached ~/.gradle/caches/modules-2 and ~/.gradle/wrapper, while explicitly excluding volatile local lock files and build scan logs: ~/.gradle/caches/*.lock.
• Cache Size Limits: GitHub Actions enforces a 10 GB limit per repository; purging volatile locks prevents cache eviction storms.

Measure build acceleration and developer feedback speed:

• Cache Hit Rate: Achieved sustained 96.4% cache hit rate across 400 daily pull request runs.
• Duration Impact: Average pipeline execution time dropped from 18 minutes down to 3 minutes 45 seconds (79% speedup).
• Compute Reduction: Slashed weekly runner minute consumption by 24,000 minutes.