FSD Frontend System Design

Part IV — The Reach · Lesson 9.1

Service Workers

In one lineA background script that survives your page, proxies its requests, and updates on its own schedule.

Where you've seen itWriting a note in the metro, closing the tab, and finding it saved to the server by the time you're above ground.

  • Time18 min
  • DiagramLifecycle states + the update trap
  • Chapter9 · Offline Support

Diagram

diagram
LIFECYCLE — and where teams get stuck

  register()
      │
      ▼
  ┌──────────┐  install event: precache the shell
  │INSTALLING│  ← self.skipWaiting() to jump the queue
  └────┬─────┘
       │ old SW still controlling the page?
       ▼
  ┌──────────┐  the new SW WAITS here until every tab
  │ WAITING  │  using the old one is closed
  └────┬─────┘  ← "I deployed but users still see the old app"
       │
       ▼
  ┌──────────┐  activate event: delete old caches
  │ ACTIVATED│  ← clients.claim() to control open pages now
  └────┬─────┘
       │
       ▼
  ┌──────────┐  intercepts fetch for every page in scope
  │ CONTROL  │
  └──────────┘

  A reload is NOT enough to activate a new SW — the old page
  must be fully closed, or you must skipWaiting deliberately.
diagram
SCOPE AND ISOLATION

  /sw.js at the root  ──► controls the whole origin
  /app/sw.js          ──► controls /app/* only

  The SW runs on its OWN thread:
    ✓ has  fetch, Cache Storage, IndexedDB, postMessage
    ✗ has NO  DOM, no window, no localStorage (sync APIs banned)
diagram
THE WRITE QUEUE — what makes "offline" actually work

  user edits offline
        │
        ▼
  write to IndexedDB (6.5)  ──► UI reads from here, instantly
        │
        ▼
  append to "outbox" store
        │
        │  connection returns (or Background Sync fires)
        ▼
  replay outbox in order ──► server
        │
        ├─ ✓ ack ──► remove from outbox, update local record
        └─ ✗ conflict ──► resolve: last-write-wins, merge, or ask

How it works

  1. Register after load so the service worker never competes with first paint.
  2. Precache the shell on install; delete old caches on activate, keyed by a version string.
  3. Decide the update policy: either skipWaiting + clients.claim (fast, risks a version mismatch between open tabs and new assets), or show a "New version available — reload" prompt. Pick deliberately.
  4. Serve reads from cache/IndexedDB, using the strategies in 6.8.
  5. Queue writes in IndexedDB and replay them on reconnect, ideally via the Background Sync API where available.
js
self.addEventListener('activate', (event) => {
  event.waitUntil(
    caches.keys().then((keys) =>
      Promise.all(keys.filter((k) => k !== CACHE_V).map((k) => caches.delete(k)))
    ).then(() => self.clients.claim())
  );
});

Trade-offs

GainCost
Works offline, instant repeat loadsA bad SW is sticky on users' devices
Background sync and pushDebugging is harder — separate thread
Full control over cachingVersion-skew bugs between tabs

Always ship a kill switch. A service worker that unregisters itself and clears caches is your only remedy if you deploy a broken one — you cannot reach those devices any other way.

Interview angle

"You deployed a fix but users still see the broken version. Why?"

  • The old service worker keeps control until every tab using it closes; a refresh doesn't replace it.
  • Either call skipWaiting and clients.claim, or surface an explicit update prompt — silence is what causes this.
  • It's also why a kill-switch SW and cache versioning are mandatory before your first production deploy.

Recap

  • Install → waiting → activated → controlling; the waiting step is where deploys appear stuck.
  • No DOM, no sync storage — the SW lives on its own thread with fetch, Cache Storage, and IndexedDB.
  • Offline writes need a queue plus a conflict rule, not just a cache.