State Management and Data Flow Architecture Questions

Design and reasoning about where and how data is stored, moved, synchronized, and represented across the full application stack and in distributed systems. Topics include data persistence strategies in databases and services, application programming interface shape and schema design to minimize client complexity, validation and security at each layer, pagination and lazy loading patterns, caching strategies and cache invalidation, approaches to asynchronous fetching and loading states, real time updates and synchronization techniques, offline support and conflict resolution, optimistic updates and reconciliation, eventual consistency models, and deciding what data lives on the client versus the server. Coverage also includes separation between user interface state and persistent data state, local component state versus global state stores including lifted state and context patterns, frontend caching strategies, data flow and event propagation patterns, normalization and denormalization trade offs, unidirectional versus bidirectional flow, and operational concerns such as scalability, failure modes, monitoring, testing, and observability. Candidates should be able to reason about trade offs between latency, consistency, complexity, and developer ergonomics and propose monitoring and testing strategies for these systems.

MediumSystem Design

47 practiced

Two microservices, ProfileService and PostService, both cache user display names. When a user updates their display name via ProfileService, design how PostService's caches get updated so posts show the new name with minimal staleness. Present at least three architectures and discuss trade-offs in complexity, latency, and failure modes.

Sample Answer

Requirements & constraints (clarify):- Functional: When ProfileService updates a user's display name, PostService must show the new name quickly.- Non-functional: Minimize staleness, low latency reads, high availability, tolerate partial failures, bounded complexity.- Scale: many users, many posts, multiple PostService instances.

Option A — Polling / TTL-based cache (simple)- Design: Each PostService instance caches display names with short TTL (e.g., 30s). On cache miss read-through to ProfileService or user DB.- Complexity: Very low to implement.- Latency: Reads often hit cache; worst-case staleness = TTL.- Failure modes: If ProfileService down, reads after TTL may fail or serve stale. High load on ProfileService if TTL too short.- When to use: Small scale, acceptable slight staleness, simple deployments.

Option B — Event-driven invalidation (recommended)- Design: ProfileService publishes "UserUpdated" events to a durable pub/sub (Kafka, SNS). PostService subscribes; on event it invalidates or updates its local cache entries. Use compacted topic or tombstones for reliability. For multi-instance PostService, either each instance subscribes or use a shared cache (see C).- Complexity: Medium—requires event pipeline and at-least-once handling.- Latency: Near real-time (ms–s), minimal staleness.- Failure modes: Event broker failures (mitigate via durable logs and retries), duplicate events (idempotent handlers), missed events (use snapshot sync/periodic reconciliation).- Benefits: Scales well and decouples services.

Option C — Centralized distributed cache + cache-aside- Design: Use Redis/Memcached as single source for cached display names. ProfileService writes new name to DB and updates Redis; PostService reads from Redis on render.- Complexity: Medium; simpler consumer logic.- Latency: Very low read latency, staleness minimal if ProfileService updates cache synchronously.- Failure modes: Single cache outage affects read latency/availability (mitigate with clustering/fallback to DB). Need to handle race between DB write and cache update (use write-through or transactions).- When to use: Many PostService instances where maintaining per-instance caches is costly.

Option D — Synchronous lookup on render (strong consistency)- Design: PostService always queries ProfileService/DB when rendering names (optionally with short local cache).- Complexity: Low logic, higher operational coupling.- Latency: Higher read latency and higher load on ProfileService; staleness = 0.- Failure modes: Tight coupling causes outages if ProfileService slow/down. Use circuit breaker, read fallback.

Trade-offs summary:- Simplicity vs freshness: Polling is simplest but higher staleness; synchronous lookup is freshest but couples services/high latency.- Scalability: Event-driven scales best and minimizes coupling; centralized cache centralizes failure but reduces duplication.- Consistency: Strongest with synchronous or cache-write-through; eventual consistency with events/polling—acceptable for display names.- Failure handling: For event-driven, add durable topics, idempotent handlers, and periodic reconciliation/snapshot sync to fix missed messages. For centralized cache, ensure high-availability cache cluster and fallback to DB.

Recommendation:- Use event-driven invalidation (Option B) as primary: ProfileService emits UserUpdated to Kafka; PostService updates/invalidate local caches idempotently. Add periodic reconciliation (e.g., daily or on startup) against ProfileService to recover missed events. For very high read scale, combine B with a distributed cache (C) as shared cache tier. Include metrics and alerting for broker lag and reconciliation failures.

EasyTechnical

48 practiced

Given nested JSON where posts contain nested comments and embedded user objects, explain why and how you would normalize that data for a client-side cache/store. Describe the before and after structures, the impact on update operations, and how normalization helps with caching and consistency.

Sample Answer

Normalizing nested JSON means converting deeply nested objects into flat, keyed entities (by id) and storing references instead of repeated objects. This makes client caches (Redux, RTK Query, Apollo, Zustand) easier to update and keep consistent.

Before (nested):

javascript

{
  post: {
    id: "p1",
    title: "Hello",
    author: { id: "u1", name: "Alice" },
    comments: [
      { id: "c1", text: "Nice", author: { id: "u2", name: "Bob" } },
      { id: "c2", text: "Thanks", author: { id: "u1", name: "Alice" } }
    ]
  }
}

After (normalized):

javascript

{
  entities: {
    posts: { p1: { id:"p1", title:"Hello", author:"u1", comments:["c1","c2"] } },
    users: { u1:{id:"u1",name:"Alice"}, u2:{id:"u2",name:"Bob"} },
    comments: { c1:{id:"c1",text:"Nice",author:"u2"}, c2:{id:"c2",text:"Thanks",author:"u1"} }
  }
}

Why and how:- Single source of truth: each user or comment exists once. Use utilities like normalizr or write simple reducers that merge by id.- Store references (ids) in parent entities to preserve relationships.

Impact on update operations:- Updating a user’s name requires updating users.u1 only; all posts/comments referencing u1 automatically reflect change—no deep traversal or duplicate updates.- Adding/removing comments updates comments map and the post’s comments array (ids), minimizing mutation scope and making optimistic updates straightforward.

How it helps caching and consistency:- Cache hits: client can fetch/merge partial entities without replacing whole nested blobs.- Cache invalidation: mark or refetch only affected entity types/ids.- Performance: reduces memory duplication, faster shallow equality checks for UI (React selectors/memoization).- Concurrency: easier to resolve conflicting updates by entity id.

In practice: normalize server responses into entities on receive, keep selectors that denormalize for UI, and write small reducers/actions that operate on entity maps to keep updates atomic and consistent.

MediumSystem Design

46 practiced

Design the data flow and synchronization architecture for an offline-first note-taking mobile app that allows editing while offline, background sync when online, conflict detection and resolution between devices, optimistic UI, and per-note version history. Describe local persistence choices, sync protocol, conflict resolution strategy, and user experience for conflicts.

Sample Answer

Requirements & constraints:- Offline-first: full read/write offline, optimistic UI, background sync when online.- Multi-device: detect & resolve conflicts, keep per-note version history.- Low latency on mobile, durable local persistence, minimal bandwidth.

High-level architecture:- Client (mobile) with local DB + sync engine ⇄ Server sync gateway + authoritative store.- Local DB: SQLite with a lightweight document layer (e.g., Room on Android or Core Data wrapper) + write-ahead log (WAL) for change queue.- Server: HTTP(S)/gRPC sync API, store versions in a document DB (e.g., DynamoDB / Postgres JSONB) with version metadata.

Local persistence & change model:- Notes stored as documents with metadata: note_id (UUID), client_id, lamport_ts, base_version_id, tombstone flag, and full content + ops optionally.- Operation log (append-only) records local edits as patches (CRDT ops or operational transforms) and per-note version entries for history.

Sync protocol:- Incremental pull/push using a checkpoint token per device (last_synced_seq).- Push: client sends batched change records (ops or full document diffs) with causal metadata.- Pull: server responds with unseen remote changes and conflict markers if concurrent divergent heads exist.- Transport: batched JSON over HTTPS with ETag/If-None-Match for efficiency; WebSocket for near-real-time optional.

Conflict resolution strategy:- Prefer CRDT (RGA or Automerge-like sequence CRDT) for text fields to auto-merge non-writes conflicts; for structured fields (title, tags) use last-writer-wins with lamport_ts or merge rules.- Detect semantic conflicts (simultaneous edits to same span) by comparing operation lineage; if auto-merge fails, create divergent branches (forks) with both versions retained and produce a merge suggestion diff.- Maintain per-note version history as immutable commits referencing parent commit(s).

User experience for conflicts:- Optimistic UI: local edits applied immediately, changes queued and shown with sync status indicator (✓ synced, ↻ syncing, ! conflict).- On auto-resolved merges: show "Merged" toast with ability to review merged diff in revision history.- On unresolved conflict: surface a lightweight UI showing both versions side-by-side, highlight differences, offer: - Accept remote / keep local - Manual edit to merge - Create merged note combining both- Provide "History" UI showing timeline of versions, author/device, timestamp, and ability to revert.

Trade-offs & scalability:- CRDTs increase client complexity and payload size but minimize manual conflicts and are well-suited for text-heavy notes.- If storage/bandwidth constrained, use operational transforms or send compressed diffs and limit history depth by retention policy.- Security: end-to-end encryption moves conflict resolution to client; still feasible with CRDTs if merges done client-side and server stores encrypted blobs.

This design balances responsiveness, correctness, and UX for largely offline mobile use while preserving full version history and user control over conflicts.

MediumTechnical

41 practiced

Discuss how GraphQL affects frontend caching and normalization strategies (for example with Apollo or Relay). What problems occur when identifier fields are missing or inconsistent, and how would you design GraphQL schema and client cache keys to support reliable normalization and cache eviction?

Sample Answer

Start with the goal: normalization makes the client cache a graph of entities keyed by stable IDs so updates/evictions are local and cheap. Libraries like Relay and Apollo normalize by combining __typename + identifier (Relay mandates a globally unique "id" via the Node interface; Apollo uses configurable keyFields).

Problems when identifiers are missing or inconsistent:- Duplicate objects: same logical entity stored multiple times under different keys → stale UI, waste memory.- Failed merges: incoming partial updates create fragmented state or overwrite unrelated entities.- Cache eviction/GC breakage: you can’t reliably evict or refetch a single entity.- Harder optimistic updates and subscriptions because you lack a deterministic key.

Schema and client design recommendations:- Provide stable, opaque global IDs (Relay Node pattern) or at minimum an "id" per object and expose __typename.- Use consistent types and field names across queries (avoid aliasing critical id fields inconsistently).- For composite identity (no single id), declare keyFields on the client (Apollo) e.g., keyFields: ["sku","region"].- Expose mutation payloads that return complete, canonical objects (id + typename) to let clients merge.- Avoid embedding deeply nested, mutable entities where normalization is desired—return references (ids) when appropriate.

Client cache/key tactics:- Set Apollo’s typePolicies with keyFields and custom merge functions for lists/pagination to prevent duplication.- Invalidate or evict by id using cache.evict({id: cache.identify(obj)}) and run garbage collection.- For optimistic UI, build payloads with the same id/typename so updates map to normalized entries.

Trade-offs:- Global IDs require server-side support and careful migration but pay off in cache consistency.- Composite keys are flexible but risk brittleness if client and schema drift.

In short: design the schema to expose stable identifiers and typename metadata, configure client keying (or Node/global-id) consistently, and implement merge/eviction rules so normalization remains reliable.

MediumTechnical

40 practiced

Describe how you would design optimistic updates and reconciliation for a complex object with nested sub-resources (for example, a project with tasks). Include how to map optimistic local ids to server ids, how to handle partial acceptance by the server, and how to revert or merge changes with minimal disruption to the UI.

Sample Answer

Situation: We need responsive optimistic updates for a complex object (project) with nested sub-resources (tasks), while safely reconciling server responses that may partially accept changes.

Approach (high-level):- Treat local state as the single source of truth for UI, and keep an authoritative server state to reconcile against.- Create a deterministic local ID scheme for new entities: client-generated temporary IDs like "tmp:uuid" and attach a version/operation log to each change.- Batch operations per user action (create/update/delete) and send them with metadata (tmp ids, parent references, op id, timestamp).

ID mapping:- When creating a task locally, assign tmp:id = "tmp:1234". Optimistically render and reference it.- Include a mapping table in client state: tmpId -> pendingPromise.- When server responds with created resource and real id, update mapping: replace tmpId with serverId across project and all pending operations. Emit a minimal patch that replaces IDs but preserves UI order and local edits.

Handling partial acceptance:- Server returns per-operation results (success, validation errors, partial accept). Use a per-op reconciliation function: - Success: replace tmp ids and merge server fields. - Partial success (e.g., create accepted but some fields rejected): merge accepted fields and surface validation errors inline on the task (non-blocking UI). Keep editable fields editable; mark server-validated fields as authoritative. - Failure: mark the operation failed, attach error reason to the task, and present undo/retry UI.

Revert vs merge with minimal UI disruption:- Use CRDT-like or patch-merge strategy: compute a minimal set of local-to-server diffs and apply them immutably so UI libraries (React) can do minimal re-renders.- Preserve local-only transient state (selection, in-place edits) by storing UI ephemeral state separate from model state; only patch model fields.- For conflicting updates (user edited same field while request pending), keep an operation queue per-entity and merge by timestamp or op-id; favor client-latest with server acknowledgement: if server returns older value, keep client edit and re-send, but surface sync status (saving/failed).- For rollback on failure, apply an inverse patch derived from the operation log so only affected fields are reverted, not the whole object.

Practical patterns and implementation tips:- Use optimistic response shapes and include original tmp ids in the request body.- Keep an operation log with id, tmpIds, inversePatch, and retry count.- Use a small example mapping update (pseudo-JS):

javascript

// mapping tmp->server id
const idMap = { "tmp:1": "srv:42" };
function applyServerCreate(resp) {
  replaceIdInModel("tmp:1", "srv:42");
  mergeFields("srv:42", resp.fields);
  clearPendingOp("op-7");
}

- Show inline validation errors without removing the optimistic item so users can correct mistakes immediately.

Why this works:- Temporary IDs and op logs let UI remain responsive and consistent.- Per-op reconciliation avoids heavy-handed full-state replaces so UI keeps context (scroll position, focus).- Minimal patches limit renders and give clear UX affordances (saving, error, retry, merged), making flow predictable for users and maintainable for engineers.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.