Design state sync across browser tabs

Requirements: what crosses the tab boundary

A tab here means one open page of our app: one document with its own JavaScript heap, its own React tree, and its own memory. Two tabs of the same site share some things on disk (cookies, localStorage, IndexedDB, the HTTP cache) but they share nothing in memory. A variable you set in tab A does not exist in tab B. Every bug in the question comes from that gap.

People do open many tabs. Power users of Gmail, Jira or Notion often keep 3 to 10 tabs of the same app open all day (an estimate, not a published number). On a phone it is usually one or two, but the browser keeps old tabs in the background, often frozen, and wakes them hours later.

The cross-tab-sync lesson teaches the browser APIs one by one: the storage event, BroadcastChannel, SharedWorker, and Web Locks basics. This guide designs the whole system of a multi-tab app on top of them. Nearby parts have their own guides, linked at the end: auth flow (sessions and refresh in one tab), shopping cart, dark mode theming (theme storage and first paint), rate-limited queue (one tab owning a request queue), offline sync engine (the outbox), and Slack and Gmail (the products that live in many tabs).

Questions to ask first

Functional requirements

• Logout everywhere: signing out in one tab signs out every tab of the app within about 1 second, and their screens stop showing private data.
• One refresh: when the access token expires, exactly one tab refreshes it and every tab uses the new token.
• Shared data stays fresh: a cart change, a read message, or a renamed ticket in one tab shows in the others without a reload.
• Settings follow: theme, language, density and notification settings changed in one tab apply in all of them.
• Drafts are safe: if the same draft is open in two tabs, the user is warned before one tab overwrites the other.
• One owner for background work: only one tab holds the WebSocket, runs polling, and runs background sync. If it closes, another takes over.
• Each tab keeps its own place: route, scroll position, open panels and selection are per tab and never synced.

Non-functional requirements

Out of scope

• Sync across devices (phone and laptop). That goes through the server and belongs to the offline sync engine, Slack and Gmail guides. Here we sync tabs of one browser profile.
• Real-time co-editing of one document by two people. That needs CRDTs or operational transforms (see the Google Docs guide). Two tabs of one user are a much smaller problem.
• Sync with other origins or iframes from other sites. We stay same-origin on purpose (see the security chapter).

What makes this hard

Syncing two tabs sounds like one line of code: post a message, listen for it. The difficulty is everything around that line. Five traits drive every decision in this guide.

1. Tabs are peers with no boss. The browser does not say which tab is the main one, and any tab can open, close or crash first. If one tab is to own the socket, the tabs must agree among themselves, and the agreement must survive a crash.
2. Tabs sleep. Chrome throttles a hidden tab's repeating timers to about once a minute after 5 minutes, and a tab can be frozen (no JavaScript runs) or discarded (thrown away and reloaded when the user returns). A frozen tab gets queued messages late, in a burst; a discarded one never gets them.
3. Messages have no order across senders and no history. Two tabs can change the cart at the same moment, and a third may see the changes in either order. A tab that opens after a change never sees its message.
4. Tabs run different code. After a 14:00 deploy, a tab opened at 13:00 runs the old bundle and a tab opened at 14:05 the new one. They share storage and channels, so old code reads what new code wrote.
5. The stakes differ by kind of state. A theme 2 seconds late is fine; a logout that never reaches a tab on a shared computer is a security bug; a draft overwritten by a stale tab loses work.

Here is the bug report that started this design. A user has the app in three tabs, and at 10:00:00 the access token expires. Each tab gets a 401 and calls POST /auth/refresh with the same refresh token cookie, within a few milliseconds of each other. The server rotates refresh tokens: the first call gets a new pair and makes the old refresh token invalid.

The second and third calls arrive 30 ms later with the old token. The server sees a used token come back, treats it as theft, and revokes the whole session, so the user is signed out of every tab. Each tab did the right thing alone; the bug is the missing coordination. That is the theme of the guide: decide who does what once, and how the others find out.

Decision 1: what must sync, and how strongly

The first decision is not an API. It is a list. Before choosing how tabs talk, sort every piece of state in the app by what goes wrong if two tabs disagree about it. The naive answers are both wrong, and it helps to see why.

The same query in two tabs: invalidate or share?

Both tabs show the cart. Tab A adds a mug, and the server answers 200 with the new cart at version 18. What should tab B do? It can get an invalidation ("cart is stale") and refetch, or get the data (the new cart) and write it into its own cache.

Sending only invalidations is simplest and always correct, but with 6 tabs open one click causes 5 extra GET /cart calls. Sending data saves those calls, but the message can be large, and B must be sure the data is newer than what it has.

This design does both, by size. A small response (a cart, a ticket, a settings object: a few KB) is broadcast as { key, version, data }, and the other tabs write it straight into their query cache (in TanStack Query that is setQueryData). A large response or a list (an inbox page, search results) is broadcast as { key, version } only, and receivers mark the query stale.

A hidden tab never refetches right away: it marks the query stale and refetches when visibilitychange says it is visible again, so five hidden tabs cost zero requests. Query caches and invalidation in general are covered in the server-state-libraries and cache-invalidation lessons.

Drafts: detect and warn, never merge silently

The user opens the same draft in two tabs, types in tab A, then later types in tab B, which still shows the old text. If B autosaves, A's paragraph is gone. Merging text from two tabs of one person is rarely worth a CRDT. A simpler rule works: one tab edits a draft at a time, and the others know it.

The tab that starts editing draft 42 asks for a Web Lock named edit:draft:42 with ifAvailable: true and holds it while the editor is open. A second tab asking for the same lock gets null back at once, so it shows a banner: "This draft is open in another tab". The banner has two buttons. Switch to that tab posts draft/focus-request, and the other tab shows a notice, since a page cannot bring another tab to the front by itself.

Edit here instead takes the lock with steal: true. The old tab's lock request then rejects, so it switches its editor to read-only and reloads the latest saved text. Because the browser releases a lock when its tab closes or crashes, no stale "someone is editing" flag is left behind. As a second guard, every save carries the draft's version, and the server answers 409 Conflict if the version is old.

Decision 2: how tabs talk to each other

Now we pick the pipe. The cross-tab-sync lesson explains each API on its own. Here we weigh them as the backbone of a whole app, against our policy: auth must reach every tab fast, server data needs versions and a way to catch up, and one tab will relay socket events to the rest.

Say the core idea out loud in the interview: messages are hints, storage is truth. If every message were lost, the app would still be correct after the next read from storage, only slower. That rule tames sleeping tabs, crashed senders and messages in the wrong order, as the consistency chapter shows.

The whole bus is one small module. It wraps BroadcastChannel, adds an envelope with a sender id, and drops messages from its own tab id. Those arrive only if the same tab opens a second channel object, for example in a worker, but the check costs nothing.

const TAB_ID = crypto.randomUUID();
const channel = new BroadcastChannel("app-sync");

export function publish(msg: SyncMessage) {
  const envelope: Envelope = { v: PROTOCOL, from: TAB_ID, at: Date.now(), build: BUILD_ID, msg };
  channel.postMessage(envelope);
}

export function subscribe(handler: (msg: SyncMessage) => void) {
  const onMessage = (e: MessageEvent) => {
    const env = parseEnvelope(e.data); // null if unknown version or shape
    if (!env || env.from === TAB_ID) return;
    handler(env.msg);
  };
  channel.addEventListener("message", onMessage);
  return () => channel.removeEventListener("message", onMessage);
}

// A page restored from the bfcache missed every message: catch up from storage.
addEventListener("pageshow", (e) => { if (e.persisted) catchUpFromStorage(); });

Decision 3: one tab in charge of the socket and timers

Some work must happen once per browser, not once per tab: the WebSocket, polling for new mail every 60 seconds, the background sync of the outbox (see the offline sync engine guide), the request queue (see the rate-limited queue guide), and the timer that refreshes the token early. With 6 tabs and no coordination, a user holds 6 sockets. At 200,000 users online that is over a million connections where 200,000 would do, and the server sends every event 6 times.

So the tabs elect a leader: one tab that does the shared work and relays what it learns to the others (the followers). The election must give exactly one leader at a time, notice fast when the leader is gone, and never leave two leaders running for long (split brain).

let duties: AbortController | null = null;

export function campaign() {
  setRole("follower");
  navigator.locks
    .request("app:leader", async () => {
      duties = new AbortController();
      setRole("leader");
      startLeaderDuties(duties.signal); // socket, polling, heartbeat replies, token timer
      await new Promise<void>((resolve) =>
        duties!.signal.addEventListener("abort", () => resolve()),
      );
    })
    .catch((err) => {
      if (err.name !== "AbortError") throw err; // AbortError: our lock was stolen
    })
    .finally(() => {
      duties?.abort(); // stop the socket and timers, whatever the reason
      duties = null;
      campaign(); // stand in the queue again as a follower
    });
}

Every way a leader can go away

For the suspended-but-holding case we add a heartbeat. A visible follower posts leader/ping on the channel every 5 seconds, and the leader answers leader/heartbeat from its message handler. The ping comes from the visible tab on purpose: browsers throttle timers in hidden tabs, not message handlers, so a healthy leader in the background still answers at once. A frozen leader does not answer at all.

After 15 seconds without an answer, the visible follower calls navigator.locks.request("app:leader", { steal: true }, ...). Hidden tabs never steal, because their throttled timers make them the most likely to be wrong about time. When the old leader wakes, its lock promise has already rejected with AbortError, so the finally above shuts its socket down among the first tasks it runs. Two sockets can overlap only for that moment.

Decision 4: auth across tabs: logout everywhere, refresh once

Auth has the strictest policy. How sessions, cookies and refresh tokens work in one tab is in the auth flow guide and the auth-tokens lesson; here we add only what changes with many tabs. This design keeps the refresh token in an HttpOnly cookie (all tabs share it, no script can read it) and the access token in memory (each tab has its own copy, valid about 10 minutes).

Logout everywhere

A user signs out in tab A. Tabs B and C still have the inbox on screen, an access token in memory, and cached messages in IndexedDB. On a shared library computer, the next person walks up to tab B. So logout must do three things in every tab, even if the network is down: stop showing private data, drop every secret, and wipe caches.

1. Tab A bumps an auth epoch: a counter in localStorage (auth:epoch = 8, with state: "signed-out"). Writing it also fires a storage event in every other tab: a second, free delivery path for the one message that must not be lost.
2. Tab A posts { type: "auth/signed-out", epoch: 8 } on the channel.
3. Every tab that sees an epoch higher than its own runs the same signOutLocally(): forget the access token, clear the query cache, delete the user's IndexedDB databases, close the socket if it leads, and location.replace("/signin") so Back does not show the inbox.
4. Tab A calls POST /auth/logout to revoke the session on the server. If that call fails, the local sign-out has still happened everywhere. The call is retried with the outbox, and the session cookie is cleared by the response or expires.

Why an epoch and not just a message? A tab that was frozen during the logout gets no message. When it wakes, it checks auth:epoch in localStorage on visibilitychange, pageshow and before every API call, sees 8 against its own 7, and signs out. The same epoch handles sign-in: if a different user signs in at epoch 9, every old tab must reload, not re-render, because its memory holds the previous user's data.

Refresh exactly once

Back to the bug from the requirements chapter. Many identity providers rotate refresh tokens for browser apps (Okta does it by default for single-page apps): each refresh returns a new refresh token and invalidates the old one. If an old one is used again, the server assumes it was stolen and revokes the whole token family. Auth0 and Okta both document this reuse detection.

Both also offer a window in which the previous token still works: Okta's grace period (30 seconds by default, 0 to 60) and Auth0's rotation overlap period (off by default). Such a window can hide the bug, but it is a server setting the client does not control, so the client must not depend on it.

export async function getFreshToken(staleToken: string): Promise<string> {
  return navigator.locks.request("auth:refresh", async () => {
    // Another tab may have refreshed while we waited for the lock.
    if (shared.token && shared.token !== staleToken && shared.expiresAt > Date.now() + 5_000) {
      return shared.token;
    }
    const res = await fetch("/auth/refresh", { method: "POST", credentials: "include" });
    if (res.status === 401) {
      signOutEverywhere("refresh-rejected"); // the session is really over
      throw new AuthError("signed-out");
    }
    const { accessToken, expiresAt } = await res.json();
    shared.token = accessToken;
    shared.expiresAt = expiresAt;
    publish({ type: "auth/token", accessToken, expiresAt, epoch: authEpoch() });
    return accessToken;
  });
}

The lock and the re-check do different jobs. The lock stops two tabs from sending the same refresh token at the same time, which is what reuse detection punishes: when the second tab gets the lock, the first call's response has already put the rotated token in the cookie. The re-check stops the second tab from refreshing at all, which keeps the server at one refresh per expiry.

Each tab keeps shared up to date from the auth/token messages. A tab that missed the message (it was frozen) has the old token, gets a 401, takes the lock, and the re-check fails, so it refreshes itself: a second refresh, but minutes later with the current cookie, which is a normal rotation and not a reuse.

Decision 5: order, versions, and catching up

Messages between tabs arrive late, out of order, twice, or never. Here is a concrete case. The cart has a mug with quantity 1. In tab A the user sets it to 2, and the server saves it as cart version 17, but the response to tab A is slow.

A moment later, in tab B, the user sets it to 3; the server saves version 18 and B's response comes back fast. B broadcasts version 18, then A's slow response lands and A broadcasts version 17. If tab C applies messages in arrival order, it ends at quantity 2 while the server says 3, and nothing corrects it until C refetches.

type Versioned<T> = { key: string; version: number; writer: string; data: T };

function isNewer(incoming: Versioned<unknown>, current?: Versioned<unknown>) {
  if (!current) return true;
  if (incoming.version !== current.version) return incoming.version > current.version;
  return incoming.writer > current.writer; // same version: tab id breaks the tie
}

export function applyRemote<T>(msg: Versioned<T>) {
  const current = versions.get(msg.key);
  if (!isNewer(msg, current)) return; // late or duplicate: ignore
  versions.set(msg.key, msg);
  queryClient.setQueryData([msg.key], msg.data);
}

A sleeping tab catches up from storage, not from messages

A tab frozen for 2 hours missed hundreds of messages. Chrome runs a frozen page's queued tasks when it resumes, so some messages may arrive late in a burst. A discarded page gets nothing, and neither does one restored from the bfcache: in Chrome, a cached page that receives a channel message is evicted from the cache instead. Replaying messages is the wrong tool anyway: we do not store them, and many would be stale.

Instead, every tab has one function, catchUp(). It runs on visibilitychange to visible, on pageshow with persisted: true, on the resume event (Chrome's Page Lifecycle API), and on online. It does four cheap reads and decides from versions:

1. Read auth:epoch. If it moved, sign out or reload, and stop here.
2. Read the settings record from localStorage (one key, under 1 KB). Apply it if its version is higher.
3. Read the version table from IndexedDB (key to version). Mark every cached query with a lower version as stale; the visible ones refetch.
4. Read app:build (the newest deployed build id that any tab has seen). If it is newer than this tab's build, show the "new version" prompt (next chapter).

The burst of old messages that may arrive after a freeze is then harmless: each one is older than what catchUp() already applied, so isNewer drops it. This is the payoff of "messages are hints, storage is truth".

Interface: the message protocol, and surviving a deploy

The tabs now share a channel, storage, and a leader. The interface of this system is the set of messages on the channel and the keys in storage. Treat it like a public API: typed, versioned, and documented, because the two ends of it are often different builds of the app.

export const PROTOCOL = 3; // bump only for breaking changes

export type Envelope = { v: number; from: string; at: number; build: string; msg: SyncMessage };

export type SyncMessage =
  | { type: "auth/signed-out"; epoch: number; reason: string }
  | { type: "auth/signed-in"; epoch: number; userId: string }
  | { type: "auth/token"; epoch: number; accessToken: string; expiresAt: number }
  | { type: "settings/changed"; version: number; writer: string; settings: Settings }
  | { type: "cache/update"; key: string; version: number; data: unknown }
  | { type: "cache/invalidate"; keys: string[]; version: number }
  | { type: "draft/editing"; draftId: string; tabId: string }
  | { type: "draft/focus-request"; draftId: string }
  | { type: "activity"; at: number }
  | { type: "leader/ping"; tabId: string }
  | { type: "leader/heartbeat"; tabId: string; socket: "open" | "connecting" | "closed" }
  | { type: "leader/request"; id: string; action: "send-ws"; payload: unknown }
  | { type: "app/hello"; build: string; protocol: number };

The leader relays server events. The socket delivers { "type": "cart.updated", "cartId": "c1", "version": 19, "cart": {...} }. The leader applies it to its own cache, writes the version to IndexedDB, and publishes cache/update with key cart.

Followers that want to send something on the socket (a typing indicator, a presence ping) post leader/request, and the leader sends it. Keep this path for small, loss-tolerant messages; writes that must not be lost go over HTTP from the tab that made them, so they never depend on another tab.

Old tab, new tab

At 14:00 we deploy build b-912, which renames cart.items to cart.lines and bumps PROTOCOL from 3 to 4. A tab opened at 13:00 still runs b-911. Without care, the new tab broadcasts a cart with lines, the old tab reads cart.items.length, and throws. Four rules prevent that:

1. Tolerant reader: a receiver validates every message (a small schema check) and ignores unknown types and unknown fields. It never throws on input from another tab.
2. Same major or nothing: a message with a different v is not parsed at all. It is only used as a signal: some tab runs another protocol.
3. Expand, then contract: for one release, new code writes both items and lines and reads either. The release after that stops writing items. Most deploys then need no protocol bump.
4. Old tabs ask to reload: a tab that sees a higher protocol or a newer app:build shows a banner, "A new version is available", with a Reload button. It does not reload by itself while it holds a draft lock or has unsaved input; it reloads on the user's click or on the next navigation.

Storage needs the same care as messages, and IndexedDB enforces it for you. When the new tab opens the database at a higher version, every old tab with an open connection gets a versionchange event, and the upgrade is blocked until they close. The old tab's handler should call db.close(), then show the reload banner.

Forgetting this handler is a classic bug: the new tab hangs on a spinner because a forgotten background tab holds the old connection. The indexeddb lesson covers version upgrades in detail.

Architecture, data model and testing

Every tab runs the same code. What differs is the role: one tab has the leader duties switched on, the others have them off. Keeping one bundle and one code path matters: any tab can become leader at any moment, so the leader code must already be loaded and tested in every tab.

How data moves

There are two directions. Reads from the server's push: the server sends an event on the one socket, which lives in the leader tab. The leader writes the data and version to IndexedDB, applies it to its own query cache, and publishes cache/update. Each follower runs applyRemote, and React re-renders only the components that read that key.

Writes by the user: the tab where the user clicked sends the HTTP request itself, gets the new version back, applies it locally, persists it, and publishes. The leader is not involved in writes, so a suspended leader can never block a click.

Data model: what lives where

Each piece of state lives in exactly one primary place. Messages only announce changes to it. The client-storage lesson compares the storage options in general; the table below is the choice for this app.

type AuthRecord = {
  schema: 1;
  epoch: number;          // bumped on every sign-in and sign-out
  state: "signed-in" | "signed-out";
  userId: string | null;
};

type SettingsRecord = {
  schema: 2;
  version: number;        // highest seen + 1 on each write
  writer: string;         // tab id, breaks ties
  theme: "light" | "dark" | "system";
  locale: string;
  density: "comfortable" | "compact";
};

type VersionRow = { key: string; version: number; savedAt: number }; // IndexedDB "versions"

type DraftRow = { draftId: string; text: string; baseVersion: number; savedAt: number }; // IndexedDB "drafts"

The schema field is for the deploy problem from the protocol chapter. A newer build that finds schema: 1 in localStorage migrates the record and writes it back with the new number; an older build that finds a schema it does not know leaves the record alone and uses defaults. Neither ever throws on a record another build wrote.

Testing many tabs

Multi-tab bugs do not show up in unit tests of one tab; they need a real browser with several pages sharing one profile. Playwright gives exactly that: pages created from the same browser context share cookies, localStorage, IndexedDB, BroadcastChannel and Web Locks, like tabs in one window. Pages from two different contexts behave like two separate profiles, which is how you test that sync does not leak between users. The general approach to end-to-end tests is in the e2e-tests lesson.

test("logout everywhere and leader hand-over", async ({ context }) => {
  const [a, b, c] = await Promise.all([context.newPage(), context.newPage(), context.newPage()]);
  for (const p of [a, b, c]) await p.goto("/inbox");

  // Exactly one tab leads.
  const roles = await Promise.all([a, b, c].map((p) => p.evaluate(() => window.__sync.role)));
  expect(roles.filter((r) => r === "leader")).toHaveLength(1);

  // Close the leader without warning; another tab takes over.
  const leader = [a, b, c][roles.indexOf("leader")];
  await leader.close({ runBeforeUnload: false });
  const rest = [a, b, c].filter((p) => p !== leader);
  await expect.poll(() => Promise.all(rest.map((p) => p.evaluate(() => window.__sync.role))))
    .toContain("leader");

  // Logout in one remaining tab signs out the other.
  await rest[0].getByRole("button", { name: "Sign out" }).click();
  await expect(rest[1]).toHaveURL(/\/signin/);
});

• Frozen or crashed leader. In Chromium, a CDP session can freeze a page: const cdp = await context.newCDPSession(page); await cdp.send("Page.setWebLifecycleState", { state: "frozen" }). Assert that a visible follower steals after 15 s (use page.clock to skip the wait), then set the state back to active and assert the old leader closed its socket. cdp.send("Page.crash") simulates a renderer crash for the hand-over test.
• bfcache. Navigate away and back with page.goBack(), then assert catchUp() ran (expose a counter in test builds).
• Old and new builds. A contract test feeds the current parser messages recorded from the previous release and asserts it never throws. Run it in CI on every change to sync-protocol.ts.
• Duplicate refresh. Expire the token in three pages at once, then assert that the mock server saw exactly one POST /auth/refresh.

Expose role, epoch and versions on a debug object only in test and development builds, and add a small "sync" panel to the in-app debug menu showing the tab id, role, last heartbeat and protocol. It pays off the first time someone reports "two of my tabs disagree".

Performance, security and privacy

Avoiding broadcast storms

A broadcast storm is when sync traffic grows faster than the changes behind it. Picture a bulk action that marks 500 emails read. If each change publishes one cache/update and each of 6 tabs answers by invalidating and refetching the inbox, that is 500 messages, 2,500 handler runs, and up to 2,500 GET requests in a second. Worse, if a receiver re-publishes what it applied, two tabs can echo a message back and forth forever.

• Never re-publish what you received. Only the tab that caused a change (or the leader, for socket events) publishes it. The isNewer check also stops echoes, since an echo is never newer.
• Batch per frame. The bus collects messages for one requestAnimationFrame (about 16 ms; in a hidden tab, where frames do not run, until the next microtask) and sends one cache/invalidate with all keys.
• Send diffs or keys, not whole lists. "Messages 1 to 500 are read, version 9,120" is a few hundred bytes; the full inbox is hundreds of KB to clone into every tab.
• Debounce settings. A slider for font size publishes once the user stops moving it for 200 ms, not on every input event.

Watch localStorage in particular. Every setItem is a synchronous write the main thread waits for, and every write also wakes every other tab with a storage event. Keep it to the three tiny keys in the data model, written only on real changes; a cache write on every socket event belongs in IndexedDB, which is asynchronous.

Measure in the Performance panel: one sync message should cost well under 1 ms to receive, validate and apply; anything that shows up as a long task (over 50 ms) and hurts Interaction to Next Paint is a bug.

Security and privacy

BroadcastChannel, localStorage, Web Locks and IndexedDB are all scoped to the origin (and, in modern browsers, partitioned further when the page is embedded as a third party). That is a feature: stay inside it.

• Never use window.postMessage to sync with other windows or iframes of another origin, and never send tokens to "*". If an embedded widget from another origin needs to know the user signed out, send it a plain signed-out event with a checked target origin, never a token.
• Treat every message as input. Validate its shape before applying it; a bug or an injected script on the same origin can post anything on the channel.
• Logout wipes, it does not hide. Every tab clears its query cache, closes and deletes the user's IndexedDB databases, and calls caches.delete for any user data the service worker cached. The server can also send Clear-Site-Data: "cache" on the logout response. Avoid its "storage" directive here: it also erases auth:epoch, the record that tells a sleeping tab it was signed out.
• Shared devices. Offer a "public computer" sign-in that keeps nothing in IndexedDB at all, and shorten the idle timeout. An idle timeout must count activity across tabs: a tab the user is typing in should keep the session alive for the others, so tabs publish a throttled activity ping (once a minute at most) and the timer runs in the leader.

Running it in the interview

This question rewards structure. Candidates who start with "I'd use BroadcastChannel" spend 40 minutes on one API. Candidates who start with "what must sync, and how strongly" lead the interview. A 45-minute plan:

Draw the architecture early, with three tabs side by side, the channel under them, storage under that, and the server on the right connected to only one tab. That one picture answers half the follow-ups before they are asked.

Follow-ups to expect

• "Why not a SharedWorker?" It removes the election, and support is now broad, but Samsung Internet lacks it and Chrome for Android only added it in 2026. You still need a fallback, and it still does not help a tab that slept. Present it as an upgrade behind the tab bus.
• "What if two tabs edit the same ticket?" One editor at a time with an edit:ticket:id lock and a banner; the save carries the base version and the server returns 409 on a stale one. Merge only if the product truly needs it, and then it is a CRDT problem.
• "The leader tab is on a slow phone in the background. Is that a problem?" Only if it stops running. The heartbeat lets a visible tab steal, and the old leader's rejected lock promise shuts its socket.
• "How do you sync across devices?" You do not, here: that goes through the server. The same versions make the two paths agree, because a tab applies whatever is newer whether it came from another tab or from the server.
• "What breaks first at scale?" Message volume in large tabs, not the number of tabs: batch, send keys and versions, and keep hidden tabs quiet.