Before shipping it, separate protocol facts, product promises, and operating cost. Mixing those layers produces confident but incorrect decisions. Quota and usage are approximate snapshots changed by other tabs and disk pressure. One preflight check cannot promise a whole file; every write can fail.
Data design covers atomic writes, concurrent access, schema migration, crash recovery, and cleanup. One successful save says nothing about power loss, full storage, or reopening with an older version.
The parts that make the design practical
Turn the important choices into durable contracts: validate inputs, assign state ownership, define cleanup, and specify fallback for older peers. Later optimization must not change those semantics.
- Preflight with headroom and disclose required space, request persistence for important work, atomically write chunks, and handle QuotaExceededError with selective cleanup.
- Define success, degraded, cancelled, and failed terminal states before UI, storage, and metrics consume the same state.
- Retries need an idempotency key, backoff, and deadline; after the deadline create a new task instead of reviving old callbacks.
The delivery standard for Browser Storage Quotas: Estimate Is Advisory and Writes Still Fail is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Keep false assumptions out of production
Production failures often appear when two individually valid actions overlap. Inspect stale messages, duplicate effects, exhausted resources, and mixed versions instead of patching only the current stack frame.
- Deleting all old data violates user intent and resume, while treating a zero estimate in private mode as a browser bug creates retries.
- Refresh and network change start two recovery paths, and duplicate side effects look like two genuine user actions.
- User or task IDs in metric labels create high-cardinality cost and leak unnecessary identity into diagnostics.
What the release gate should inspect
Observe both endpoints, persisted records, and operational signals during verification. One button state or one successful response cannot prove the complete loop.
- Transfer under multi-tab competition, near-full disk, private mode, and eviction; errors stay clear, committed chunks remain consistent, and cleanup is user-scoped.
- Drive the state machine with reordered, duplicate, and delayed messages, proving stale versions are ignored and explicit stop survives recovery.
- Use fault injection to prove alerts precede user reports and operators can locate the failing phase from bounded evidence.
A capability becomes maintainable when it degrades safely, repetition adds no side effects, and its signals reveal a fault before user reports do.