Frontend State and Data Architecture Questions

Designing scalable frontend application architecture and managing application state and data flow across large code bases. Covers component hierarchy, folder and module organization, separation of concerns, and patterns for composing UIs so they remain maintainable as the application grows. Includes evaluating and selecting state management approaches such as centralized stores versus local component state, context based mechanisms, and third party state libraries; explaining trade offs among options, strategies to avoid prop drilling, techniques for lifting state up, and patterns for predictable data flow. Also covers data persistence concerns within frontend applications including local storage, client side databases, serialization and hydration, handling configuration changes and process restarts, caching strategies, offline support, synchronization with remote back ends, optimistic updates, side effect management, testing of stateful code, and approaches to incrementally migrate or modularize state in large teams.

MediumSystem Design

74 practiced

How would you synchronize application state across multiple tabs or windows of the same origin? Describe options including localStorage events, BroadcastChannel, SharedWorker, and how you'd handle edge cases like many open tabs, race conditions, and ensuring idempotency of updates.

Sample Answer

**Clarify goal & constraints**- Keep UI/UX consistent across same-origin tabs; tolerate network disconnects; avoid heavy memory/CPU; support many tabs.

**Options (when to use)**- localStorage + storage event - Pros: simple, works widely - Cons: event doesn't fire in same tab; events are string-based; possible race if many updates- BroadcastChannel - Pros: real-time, message objects, low latency, simple API - Cons: per-origin channel, not supported in very old browsers- SharedWorker - Pros: single worker instance shared by all tabs — good for centralized logic/state - Cons: complexity, worker lifecycle, limited Safari support- Server-backed (WebSocket / SSE) - Use for cross-device sync or authoritative state; combine with local channels for local tabs

**Design & implementation patterns**- Use BroadcastChannel for most cases; fallback to localStorage event if unsupported; use WebSocket for server-authoritative updates.- Encode messages with: { id: uuid, type, seq, payload, ts }- Maintain last-seen seq per origin to order messages; ignore messages older than last processed id.

**Handling edge cases**- Many open tabs: debounce/throttle frequent updates; elect leader (SharedWorker or leader-election via localStorage lock) for expensive ops.- Race conditions: include monotonic sequence numbers or vector clocks; reject out-of-order messages; use optimistic updates with conflict resolution rules (last-writer-wins or merge function).- Idempotency: attach unique operation ids and make handlers idempotent — ignore duplicate ids; persist processed ids in memory or IndexedDB for longer deduplication.- Recovery: on tab open, request full state snapshot from leader (BroadcastChannel request + response) or read authoritative server state.

**Example flow**- On local change: create op { id, seq, payload }, apply locally, broadcast via BroadcastChannel; server receives and validates; server broadcasts back; tabs reconcile using op ids and seq.

This approach balances simplicity (BroadcastChannel) with robustness (op ids, seq, leader election, server reconciliation) appropriate for full‑stack responsibilities.

HardSystem Design

151 practiced

Design a synchronization protocol that supports optimistic updates and client-side undo/redo semantics. Requirements: the client should allow local undo even after some operations are synced, handle server reconciliation, and cope with concurrent edits from other clients. Discuss operation logs, causality metadata, compaction, and undo implementation details.

Sample Answer

**Clarify goals & constraints**- Client must be snappy (optimistic local updates), allow local undo/redo even after some ops are synced, and support reconciliation with concurrent edits from other clients. Eventual consistency acceptable.

**High-level approach**- Use an append-only operation log (per-client + global) + causality metadata (vector clock or dotted version vectors) and an operation transformation (OT) or commutative CRDT foundation for concurrent resolution.- Undo is implemented as a new logical operation: the inverse op appended to the log with proper causal dependencies, not a local “revert state” only.

**Operation log & metadata**- Each op: { op_id: clientId:seq, client_id, seq, payload, deps: vector_clock, timestamp }- Server keeps merged log and broadcasts deltas. Clients keep local log + shadow state.- Causality: use dotted version vectors so each op records which prior ops it causally depends on. This lets us know whether an undo is safe or needs transformation.

**Undo/redo semantics**- Represent undo as an explicit inverse operation (INV) referencing target op_id(s). Example: INV(op123) with deps = current vector.- When user hits undo: - Locally apply inverse immediately (optimistic). - Append INV to local log and send to server.- If server sees concurrent conflicting edits: transform INV against concurrent ops (OT) or use CRDT merge rules. The inverse should be transformable: INV = transformInverse(targetOp, concurrentOps).- Redo = append original op again or append a re-inverse of the INV.

**Reconciliation & concurrent edits**- Server merges using causality: apply ops in causal order; for concurrent ops apply deterministic transform/merge rules.- Server returns acknowledgements with canonical vector_clock and transformed ops if necessary.- Client on ack: reconcile local shadow by replaying server-supplied operations; if an INV was transformed, adjust local undo/redo stacks to reflect new op_ids/dependencies.

**Compaction & checkpointing**- Periodically create checkpoints: snapshot state + compacted tombstone of applied ops up to a known vector clock. Keep mapping from original op_ids to checkpoint basis for undo history limits.- Keep recent ops (sliding window) to enable undo; older ops may be compacted and make deep undo impossible—communicate limits to UI.- Compaction also garbage-collect operations whose inverses are acknowledged and no longer needed for causal dependency.

**Edge cases & UX**- If undo targets an op that other clients have built upon, produce transformed INV that semantically undoes original intent as much as possible; if impossible, present conflict UI.- Provide optimistic UI indicators (e.g., “undo pending sync”) and disable cross-client destructive undos past compaction boundary.

**Example flow**- User A inserts “hello” locally -> Op A:insert(seq1) applied locally, sent.- User B concurrently deletes character -> Op B:delete(seq1).- A hits undo -> create INV(A:insert(seq1)), send. Server transforms INV against B:delete and applies; both clients receive canonical transformed ops and reconcile.

This design balances UX (instant undo), correctness (causality + transform/CRDT), and operational concerns (compaction, limits). Implementation choices: OT when edits are complex sequences (text editors), CRDTs when commutativity simplifies merges; use vector clocks for precise causal tracking.

EasyTechnical

75 practiced

In a React-based application, explain the difference between component props and component state. Provide a short example showing when to use props vs local component state, and describe the concept of ownership, immutability, and typical lifecycle for each.

Sample Answer

**Props vs State — short definition**- Props: Read-only inputs passed from parent to child. Immutable inside the child; child should not modify them.- State: Local, mutable data managed by the component (or via hooks). Controls UI and can change over time.

**Ownership, Immutability, Lifecycle**- Ownership: Props owned by parent; state owned by the component that declares it.- Immutability: Props treated as immutable in children; state changes via setState/useState updater.- Lifecycle: Props change when parent re-renders with new values; state changes trigger the component's own re-render and persist until unmounted.

**When to use which — example**- Use props for configuration and data flow from parent (e.g., item list, callbacks).- Use state for UI ephemeral data (e.g., input values, toggles).

Example (React function component):

jsx

// Parent owns items and passes them via props
function TodoList({ items }) {
  return items.map(item => <TodoItem key={item.id} item={item} />);
}

// Child owns local UI state (editing mode)
function TodoItem({ item }) {
  const [isEditing, setIsEditing] = useState(false); // local state
  return (
    <div>
      {isEditing ? <input defaultValue={item.text} /> : <span>{item.text}</span>}
      <button onClick={() => setIsEditing(v => !v)}>{isEditing ? 'Save' : 'Edit'}</button>
    </div>
  );
}

Reasoning: item text lives in a shared parent (props) so multiple components stay consistent; editing toggle is local UI state owned by the item component.

HardTechnical

144 practiced

Discuss security and privacy considerations for persisting data client-side (localStorage, IndexedDB, Cache API). Cover what types of data should never be stored, encryption-at-rest approaches, same-origin policy implications, third-party script risks, and how to minimize exposure of PII when persisting application state.

MediumTechnical

74 practiced

Describe a testing strategy for stateful React components that interact with a global store and network. Cover unit tests, integration tests, mocking network requests (MSW), testing optimistic updates and rollback, and test reliability in CI. Give examples of what to assert in each case.

Sample Answer

**Approach (brief)** Test at three levels: unit tests for pure logic and local state, integration tests for component+store+network behavior, and end-to-end for user flows. Use Jest + React Testing Library (RTL) for unit/integration, MSW to mock network, and deterministic fake timers or utilities to make CI reliable.

**Unit tests** - Isolate component logic and local state (use shallow render or render with minimal provider). - Mock global store selectors/actions. - Assert: local state changes, callback calls, conditional rendering. Example assertions: "button disabled while localValidation=false", "onSave called with transformed payload".

**Integration tests (component + store + network with MSW)** - Wrap component with real Redux/Context provider and MSW handlers for API. - Test optimistic update: simulate user action, assert UI shows optimistic state immediately, then on MSW success assert final state persisted; on MSW failure assert rollback to previous state and error shown. Example assertions: "item appears in list immediately after click", "on 500 response item removed and toast with 'Failed' shown".

MSW handler example:

import { rest } from 'msw';
export const handlers = [
  rest.post('/api/items', (req, res, ctx) => {
    return res(ctx.status(201), ctx.json({ id: '123', ...req.body }));
  }),
];

RTL optimistic test sketch:

// render with store
user.click(screen.getByText('Add'));
expect(screen.getByText('New item (saving...)')).toBeInTheDocument(); // optimistic
// advance async
await screen.findByText('New item'); // persisted

**Mocking network failures** - Change MSW handler to return 500 for specific tests to validate rollback path.

**Test reliability in CI** - Avoid real network, use MSW in node mode. - Use fake timers only where deterministic; prefer await waitFor/ findBy* over arbitrary setTimeout. - Reset handlers and store between tests, clear mocks, and run tests in isolated JSDOM. - Add retry/backoff simulation tests but keep them fast by mocking timing.

**What to assert summary** - Unit: state transitions, function calls, small DOM changes. - Integration success: optimistic UI, API called with correct payload, final persisted state. - Integration failure: rollback state, error UI, no persisted action. - CI: tests deterministic, no flaky timers, MSW used for all network calls.

Unlock Full Question Bank

Get access to hundreds of Frontend State and Data Architecture interview questions and detailed answers.

Join thousands of developers preparing for their dream job.