# Mission: IndexedDB (client storage)

## Why
As a frontend engineer, you want durable judgment about **where browser data lives** — not a one-off `indexedDB.open` tutorial. When a feature needs offline drafts, large structured caches, or multi-tab durable state, you should pick the right storage API, defend that choice in design reviews, and spot deal-breakers early (quotas, eviction, schema migrations, sync policy).

## Success looks like
- Given a product requirement, choose among memory, session/local storage, cookies, Cache API, OPFS, and IndexedDB (and say why)
- Know what IndexedDB gives you (async, structured, origin-scoped, large) — and what it does not (not SQL, not sync truth with the server)
- Spot deal-breakers early (main-thread sync storage abuse, wrong tool for HTTP assets, migration cost, eviction, multi-writer conflicts)
- Defend the choice in a design review with clear constraints

## Status
**In progress** — core API shape (spectrum → open → CRUD → indexes) done from lessons; external MDN deep-reads still deferred. Next: deal-breakers, then decision playbook.

## Constraints
- Frontend-first: system design decisions and browser APIs, not DBA theory
- Sibling track to SSE and Web Workers: decision fluency first; light hands-on later if useful
- Short interactive lessons; optimize for retention over speed
- Learner already has FE system-design framing from SSE + Workers tracks

## Out of scope
- Full offline PWA / Service Worker architecture (comparison only until a later mission)
- Building a production sync engine / CRDT framework
- SQLite-wasm / OPFS deep dives beyond “when that family wins”
- Server databases, ORMs, and backend schema design