Как только приложение работает без сети, встаёт вопрос: где физически лежат данные. Данные разной природы требуют разных хранилищ и правил. HTTP-ответы, доменные записи и ещё не подтверждённые сервером команды - три разные сущности, и смешивать их в одном контейнере значит закладывать баги. Полезно сразу развести клиентское состояние по трём слоям.

Первый слой - Cache Storage: программируемое хранилище пар запрос-ответ (Request и Response), которым управляет service worker. Сюда кладут app shell - статический каркас: HTML, скрипты, стили, шрифты, - картинки и, при желании, ответы на GET к API. Cache Storage мыслит в терминах HTTP: ключ - запрос, значение - готовый ответ. Типичная ошибка - принимать его за базу доменных объектов: он про возврат того же ответа, что и сеть, а не про сущности и связи.

Второй слой - IndexedDB: встроенная в браузер транзакционная база с объектными хранилищами и индексами. Здесь живут настоящие данные приложения: сущности, индексы, blob-объекты и outbox - очередь исходящих команд. IndexedDB - durable-хранилище, но с ценой: у него есть схемы и версии; критичные данные без миграций хранить нельзя - обновление схемы однажды сломает доступ к уже созданному.

Третий слой - состояние в памяти: черновик в поле ввода, выделения, временный оптимистичный статус до подтверждения. Самый быстрый и самый ненадёжный: исчезает при перезагрузке вкладки. Ошибка - принимать его за долговременное хранилище. Оптимистичное обновление в памяти - UX-приём, а не гарантия сохранности. Пока запись не легла в IndexedDB, считайте, что её нет.

Приложим это к Offline Notes. Заметки, очередь outbox и запись meta (курсор последней синхронизации) лежат в IndexedDB: доменные данные, обязанные пережить перезапуск. App shell идёт в precache Cache Storage при установке worker. GET-ответы кешируем, только если это полезный слой. Отдельное правило: команды на изменение никогда не кешируются - новая заметка получает client-generated ID (создаётся на клиенте до отправки) и durable-запись в outbox.