Cross-Tab Sync via SharedWorker Architecture

Open six tabs of a trading dashboard micro-frontend and you get six independent WebSocket connections, six IndexedDB writers racing on the same object store, and six divergent copies of client-side state the instant one tab misses a push update. Multiply that by a corporate proxy throttling concurrent connections per origin and you have a production incident. The fix is not “just use localStorage events” — that approach cannot arbitrate write conflicts or multiplex a single upstream socket. What you need is a proper SharedWorker architecture that centralises network I/O and state ownership behind a single execution context, regardless of how many tabs the user has open.

This article covers the design, implementation, and failure semantics of using a SharedWorker as the single source of truth for cross-tab state in a micro-frontend estate, including the leader-election fallback required for browsers that refuse to implement it.

#The Problem: N Tabs, N Sockets, Zero Consistency

Most micro-frontend shells are composed independently per browser tab — each shell instance boots its own Redux/Zustand store, opens its own WebSocket to the pricing gateway, and independently hydrates from IndexedDB on load. This produces three concrete failure classes:

• Connection fan-out: N tabs open N WebSocket connections to the same backend, multiplying gateway load and burning through per-origin connection limits (Chrome caps at 255 sockets per origin/process, but corporate proxies are often far stricter).
• Write races: Two tabs writing to the same IndexedDB record concurrently produces last-write-wins corruption with no application-level arbitration.
• State drift: A tab backgrounded by the browser’s tab-throttling scheduler stops receiving timely updates, then wakes up and overwrites fresher state held in a foreground tab.

A SharedWorker solves all three because it is a single JavaScript execution context shared across every same-origin browsing context — tabs, iframes, even other workers — connected via MessagePort. One socket, one IndexedDB writer, one authoritative state tree, N read-only subscribers.

#Architectural Breakdown: Why a SharedWorker Architecture Wins Over BroadcastChannel Alone

BroadcastChannel is frequently proposed as a lighter alternative, but it only solves the fan-out problem for messages already produced — it cannot own the network connection or arbitrate writes, because every tab still runs its own JavaScript instance. A SharedWorker architecture differs structurally: the worker itself becomes the network client and the database owner, and tabs become dumb rendering surfaces that subscribe to a port.

#Leader Election Inside the SharedWorker Architecture

The SharedWorker’s lifecycle is tied to the number of connected ports — it spins up on the first connect event and is eligible for garbage collection once the last port disconnects. This gives you free leader semantics: the worker itself is the leader, and there is no need for a distributed lock manager across tabs. Election only becomes necessary as a fallback for Safari and older WebViews that never shipped SharedWorker — there you elect a leader tab using the Web Locks API and have that tab behave as the broker via BroadcastChannel.

#Implementation Logic

Implementing this SharedWorker architecture in production involves four discrete stages: worker registration, port handshake, message protocol design, and graceful teardown.

#1. Registering the Worker from Each Micro-Frontend Shell

1// client.js — loaded by every micro-frontend shell instance
2const worker = new SharedWorker('/workers/state-broker.js', { name: 'state-broker-v3' });
3
4worker.port.start();
5
6worker.port.onmessage = (event) => {
7  const { type, payload } = event.data;
8  switch (type) {
9    case 'STATE_PATCH':
10      applyPatch(payload); // JSON-patch applied to local read-only store
11      break;
12    case 'CONN_STATUS':
13      updateConnectionBadge(payload.status);
14      break;
15  }
16};
17
18function dispatchAction(action) {
19  worker.port.postMessage({ type: 'ACTION', payload: action, tabId: window.__TAB_ID__ });
20}

#2. The Worker Itself: Single Owner of Network and Storage

1// state-broker.js — runs once, shared across all connected tabs
2const ports = new Set();
3let socket;
4let stateVersion = 0;
5
6function connectUpstream() {
7  socket = new WebSocket('wss://gateway.internal/prices');
8  socket.onmessage = (msg) => {
9    stateVersion += 1;
10    broadcast({ type: 'STATE_PATCH', payload: JSON.parse(msg.data), v: stateVersion });
11  };
12  socket.onclose = () => setTimeout(connectUpstream, backoff(stateVersion));
13}
14
15function broadcast(message) {
16  for (const port of ports) port.postMessage(message);
17}
18
19self.onconnect = (event) => {
20  const port = event.ports[0];
21  ports.add(port);
22  port.start();
23
24  port.onmessage = (e) => {
25    if (e.data.type === 'ACTION') handleAction(e.data.payload);
26  };
27
28  port.onmessageerror = () => ports.delete(port);
29  if (ports.size === 1) connectUpstream(); // first tab triggers connection
30};

#3. Cross-Origin Isolation for Advanced Cases

If your SharedWorker architecture needs SharedArrayBuffer for zero-copy state hand-off (common when the worker is also decoding a binary market-data feed), you must serve the shell under cross-origin isolation headers, or the browser silently disables the buffer:

1location / {
2    add_header Cross-Origin-Opener-Policy "same-origin" always;
3    add_header Cross-Origin-Embedder-Policy "require-corp" always;
4    add_header Cross-Origin-Resource-Policy "same-origin" always;
5}

Full behaviour of these headers is documented in the MDN SharedArrayBuffer reference — treat this as mandatory reading before enabling COEP on a shell that embeds third-party iframes, since it will break any cross-origin resource lacking a matching CORP header.

#4. Graceful Port Teardown

Tabs close without warning, so the worker must detect dead ports rather than trust an explicit disconnect message. Use a heartbeat rather than relying on onmessageerror alone, since a frozen background tab won’t fire it:

1setInterval(() => {
2  for (const port of ports) {
3    try {
4      port.postMessage({ type: 'PING' });
5    } catch {
6      ports.delete(port);
7    }
8  }
9  if (ports.size === 0) socket?.close();
10}, 15000);

#Failure Modes & Edge Cases

The primary weakness of a SharedWorker architecture is that it introduces a single point of failure per browser process. If the worker throws an uncaught exception, every tab loses its data feed simultaneously rather than just one. Design considerations follow.

• Worker crash without restart signal: an unhandled exception in the worker terminates it silently; tabs see no onerror unless you explicitly attach worker.onerror on every port. Always wrap handleAction in try/catch and report failures back over the port rather than letting them propagate.
• Version skew across shell deployments: if tab A loads shell v12 and tab B loads shell v13 after a deploy, both may connect to the same cached SharedWorker instance (keyed by URL + name). Version the worker script path (state-broker-v13.js) so a deploy forces a clean worker restart rather than mixing message schemas.
• Safari and iOS WebViews: no SharedWorker support at all on iOS Safari as of current WebKit releases. Your fallback path must fully replicate broker semantics using a leader-elected tab and BroadcastChannel, tested independently — don’t assume feature parity.
• DevTools inspection gaps: SharedWorkers don’t appear in the standard tab console; debug via chrome://inspect/#workers or Firefox’s about:debugging, and budget extra triage time during incidents because stack traces are harder to correlate with a specific tab.
• Storage quota contention: because the worker is now the sole IndexedDB writer, a slow transaction blocks state delivery to every tab, not just one. Batch writes and keep transactions short-lived to avoid head-of-line blocking
  The KBY Lexicon

  Head-of-Line Blocking (HOL Blocking)

  A stalled unit of work at the front of a strictly ordered queue or channel blocks all independent units queued behind it, even though they are individually ready to proceed.

  Read Full Context
  across the whole browser process.

#Scaling & Security Trade-offs

A SharedWorker architecture trades per-tab isolation for resource efficiency, and that trade needs to be justified against your actual concurrency profile before adoption. Compare it against the alternatives your team is likely already running as part of broader architectural patterns for micro-frontend composition:

• Connection cost: SharedWorker reduces N WebSocket connections to 1 per browser process; BroadcastChannel-only designs still open N connections, one per tab, so gateway load scales linearly with tabs opened rather than users.
• Fault isolation: per-tab sockets fail independently (better isolation, worse efficiency); a shared broker fails for the whole process at once (worse isolation, better efficiency) — choose based on whether your product tolerates a full-process reconnect glitch.
• Browser coverage: Chrome, Edge, and Firefox support SharedWorker fully; Safari desktop supports it; iOS Safari and iOS WebViews do not, forcing a dual-implementation maintenance burden.
• Security surface: a compromised micro-frontend bundle running inside a tab can post arbitrary ACTION messages to the shared port. Validate and schema-check every inbound message inside the worker — never trust e.data shape, since it now represents a trust boundary between origins-in-practice even though technically same-origin.
• Memory footprint: a single long-lived worker holding cached state for the session lifetime avoids the repeated rehydration cost paid by N independent tab stores, at the cost of one process holding a growing heap that needs explicit pruning logic.

For estates running more than a handful of concurrently open tabs per user — trading terminals, admin consoles, ops dashboards — the connection and consistency savings from a SharedWorker architecture comfortably outweigh the added debugging complexity, provided the Safari fallback path is treated as a first-class implementation rather than an afterthought.