Architecture Decision

I have a Chrome extension that needs to sync user data across devices. Should I use Chrome's built-in storage.sync API or implement my own sync layer with a backend? The data is about 50KB per user, updated frequently (every few minutes), and includes nested objects with arrays.

{/* Chain of thought reasoning */} }> Analyzing data size and sync limits chrome.storage.sync has a total limit of 102,400 bytes and 512 items max. At 50KB per user, that's within the total limit but leaves little headroom. Each item is capped at 8,192 bytes, so nested objects would need splitting. Write operations are throttled to 120/minute in normal mode, 1,800/hour. }> Evaluating update frequency constraints "Updated every few minutes" means roughly 20-30 writes per hour. That's well within the 1,800/hour limit. But if the data has nested objects with arrays, each update might need to write multiple storage items (due to the 8KB per-item limit), multiplying the write count. 50KB / 8KB = ~7 items minimum, so 7 * 30 = 210 writes/hour. Still within limits. }> Considering conflict resolution Chrome storage.sync uses last-write-wins. For nested objects updated from multiple devices simultaneously, this could cause data loss. If a user has the extension open on laptop and desktop, and both modify different array elements, the last write overwrites the other's changes. A custom backend could use CRDTs or operational transforms for proper merging. }> Weighing implementation complexity Custom backend means: server costs, auth, API design, offline handling, retry logic, and maintenance. Chrome storage.sync is free, built-in, handles offline automatically, and requires zero infrastructure. For a personal tool, the operational burden of a backend is significant. {/* Final answer */} {`Given your constraints, I'd recommend a **hybrid approach**: ### Use \`chrome.storage.sync\` as primary, with a chunking strategy 1. **Split your 50KB into logical chunks** -- group related data into objects under 8KB each. Use a manifest key that tracks which chunks exist and their versions. 2. **Implement delta syncing** -- instead of writing the full dataset every time, only write the chunks that changed. This keeps you well under rate limits. 3. **Add a simple conflict guard** -- store a \`lastModifiedBy\` device ID and timestamp in each chunk. On read, if you detect a conflict, merge arrays by union rather than overwrite. \`\`\`typescript interface SyncChunk { version: number; deviceId: string; updatedAt: number; data: Record; } // Write only changed chunks async function syncChunks(changes: Map) { const batch: Record = {}; for (const [key, chunk] of changes) { batch[\`chunk_\${key}\`] = { ...chunk, version: chunk.version + 1 }; } await chrome.storage.sync.set(batch); } \`\`\` ### When to upgrade to a backend Move to a custom sync layer if: - Data grows beyond **80KB** (hitting limits) - You need **real-time collaboration** (multiple devices editing simultaneously) - You want **version history** or undo across devices - You add team/sharing features`}