How do you architect Svelte stores to minimize WebSocket re-renders?

What's really being asked

Your understanding of Svelte's store contract and granular reactivity. Interviewers want to see that you know every subscriber to a writable is notified on every set, which means a single global store updated by a WebSocket fans out unnecessary renders to any component holding a subscription. They also want to see architectural discipline, using the store API to push precision upstream rather than filtering noise downstream.

A GOOD ANSWER COVERS four things in order. First, split the monolith. Instead of one writable containing the entire WebSocket payload, create domain-specific writable or readable stores for each concern, such as user, notifications, or game entities. This narrows the blast radius by design. Second, use derived stores as selectors. When you must keep a normalized global state, export derived stores that pluck only the slice a component needs. Svelte's derived store only notifies its own subscribers when the returned value changes by reference inequality, so if a component subscribes to derived(global, s => s.chat) it will not re-render when the unrelated player slice mutates. Third, encapsulate the WebSocket side effect inside a readable or custom store so the update logic is co-located and external components cannot accidentally call set. Fourth, ensure selector stability. If your derived function returns a new object literal every run, safe_not_equal will see a new reference and trigger anyway. Return stable references, existing sub-objects, or primitive values.

COMMON WRONG ANSWERS include suggesting manual diffing inside onMount or reactive statements, which still runs on every parent emission and wastes cycles. Another red flag is returning a deep clone from derived to enforce equality; this breaks reference stability and forces re-renders. Proposing Context as a drop-in replacement is also weak because Context is not reactive by default and does not solve broadcast semantics.

LIKELY FOLLOW-UPS include how to handle arrays where only one element changes, whether you would use Svelte 5 runes and fromStore to bridge legacy stores, and how to batch or debounce high-frequency WebSocket frames before they hit the store.

A concrete example

Imagine a trading dashboard with a WebSocket pushing market data. A single writable holds quotes, orders, and alerts. The alert banner component should import const alerts = derived(marketStore, m => m.alerts) and use alerts. When a new quote arrives, marketStore updates, but derived sees the alerts reference is unchanged and does not wake the banner component. The quote strip component imports its own derived slice. Each panel only re-renders when its own data changes.