# Mission: Cache API (Cache Storage)

## Why
As a frontend engineer, you want durable judgment about **HTTP resource caching in the browser** — not a one-off `caches.open` tutorial. When a feature needs offline shells, asset precaching, or runtime response caching, you should pick the Cache API (usually with a service worker), defend that choice in design reviews, and spot deal-breakers early (versioning, opaque responses, HTTP-cache interaction, quotas, stale content).

## Success looks like
- Given a product requirement, choose among memory, Web Storage, IndexedDB, OPFS, and Cache Storage (and say why)
- Know what Cache Storage stores (Request/Response pairs) — and what it does not (not a general entity DB; not automatic multi-device truth)
- Spot deal-breakers early (wrong tool for structured app data, missing cleanup/versioning, opaque responses, fighting the HTTP cache, assuming forever-durability)
- Defend the choice in a design review with clear constraints (and name a caching strategy when a service worker is in play)

## Status
**Complete** — lessons 1–5 done (lesson-first path; external primaries optional). Keep `reference/decision-playbook.html` + `integration-checklist.html` for design reviews.

## Constraints
- Frontend-first: system design decisions and browser APIs, not full PWA product design
- Sibling track to IndexedDB, SSE, and Web Workers: decision fluency first; strategies and hands-on after the spectrum
- Short interactive lessons; optimize for retention over speed
- Learner already has FE storage framing from the IndexedDB track (Cache API was comparison-only there)

## Out of scope
- Full Service Worker lifecycle / Workbox deep dives beyond what’s needed to use Cache Storage correctly
- Building a production offline sync engine or CRDT layer
- IndexedDB / OPFS implementation depth (already covered or separate missions)
- Server-side CDN / reverse-proxy cache configuration as the main topic