Data Synchronization Across Tabs and Devices

The plain-language idea

A user with the same app open in two browser tabs, or logged in on two different devices, expects a reasonably consistent experience: marking a notification read, changing a setting, or logging out in one place should ideally show up in the other without a manual refresh. This sounds like one requirement — "keep the UI in sync" — but it's actually two genuinely different problems that need two different mechanisms, and conflating them is an easy gap to fall into.

Same browser, different tab. Two tabs open to the same origin, in the same browser, can talk to each other directly:

• The BroadcastChannel API lets same-origin tabs and windows send messages directly to each other — the standard modern mechanism for cross-tab communication, with no server round-trip involved at all.
• localStorage's storage event is an older, more universally-supported fallback: it fires in other tabs (never the tab that made the change) whenever localStorage is written to in one tab — a real, still-useful alternative when broader compatibility matters more than BroadcastChannel's cleaner API.

Different device entirely. Two different devices have no direct browser-level channel between them at all — there's no local mechanism that reaches across machines. This is a genuinely different problem that has to go through the server and the real-time layer covered earlier in this track: a change made on one device gets pushed to the server, and the other device learns about it through whatever real-time mechanism (polling, SSE, or a WebSocket) was chosen for that feature, using the decision framework from the real-time-choice lesson.

See it in a real thing: marking a notification read across tabs and devices

A user opens the same app in two tabs and marks a notification read in one. In the other tab, the fix is same-browser: a storage event or a BroadcastChannel message tells that tab's notification store to update its state, with zero network involved.

Now the same user opens the app on their phone. The phone has no way to know a browser tab on their laptop just did anything — the only path is: the laptop's tab tells the server the notification is read, and the phone finds out through whatever real-time channel the app uses for that data (or, at minimum, the next time it re-fetches). Recognizing that these are two separate fixes, not one, is exactly the distinction this lesson is about.

What people usually miss

Watch out

• "Keep tabs in sync" and "keep devices in sync" are two separate problems that are easy to conflate into one design, but they need genuinely different mechanisms — missing that distinction is a real, common gap in an otherwise solid answer.
• The storage event only fires in other tabs, never the tab that made the change. A design that expects the originating tab to also receive its own storage event will silently miss updating itself.
• BroadcastChannel and localStorage's storage event never leave the browser. Neither one is a substitute for real-time sync across devices — they solve a same-browser problem only, and reaching for either one when the actual requirement is cross-device sync is a mismatch.
• Same-browser sync is close to free; cross-device sync always costs a network round-trip. Treating both as equally "instant" in a design glosses over a real cost difference worth naming out loud.

Why this matters in interviews

Prompts that mention multiple open tabs or multi-device usage are specifically testing whether a candidate separates "same browser" from "different device" instead of reaching for one real-time solution and assuming it covers both — a mistake compact enough to make in the first thirty seconds and costly enough to undermine the rest of the answer.