Q283: Frontend Domain Modeling State Ownership and Data Flows

What Interviewers Want To Evaluate

Interviewers want to know whether you can model frontend data before choosing state libraries.

They are checking whether you can identify entities, relationships, derived state, URL state, server state, local drafts, optimistic updates, and realtime changes.

Short Interview Answer

Frontend domain modeling means identifying the product entities, relationships, state categories, ownership boundaries, and data flows that the UI depends on. I separate server state, URL state, form state, local UI state, draft state, optimistic state, and realtime state. Then I decide which state belongs in the URL, which belongs in server cache, which belongs in component state, and which needs persistence. Good state architecture prevents duplication, stale views, and confusing update paths.

Detailed Interview Answer

State bugs often come from unclear ownership.

The team may ask:

should this be in Redux?
should this be in Context?
should this be in URL params?
should this be in React Query?
should this be in localStorage?

Those questions are easier after domain modeling.

Identify Entities

Start with entities.

For a learning platform:

Question
Volume
Batch
Topic
ProgressRecord
PracticeSnippet
User
MockInterview
PDFExport

For each entity, define:

id
owner
fields
relationships
lifecycle
permissions
cache behavior

Relationships

Relationships matter.

Examples:

Volume has many Questions
Batch has many Questions
Topic groups many Questions
User has many ProgressRecords
Question may have many PracticeSnippets

Relationships drive navigation, API shape, and cache invalidation.

State Categories

Separate state categories:

server state
URL state
form state
local UI state
draft state
optimistic state
derived state
realtime state
persistent client state

Each category has different rules.

Server State

Server state is owned by the server.

Examples:

user profile
cloud progress
team membership
question metadata from CMS
export status

The client caches it but does not own truth.

Mutations should update server state through defined contracts.

URL State

URL state is shareable and navigational.

Examples:

search query
filters
sort
selected tab
page cursor
question slug
topic slug

If reloading or sharing the page should preserve it, consider URL state.

Form and Draft State

Form state is in-progress user input.

Draft state may need persistence.

Examples:

answer draft
practice code snippet
search box text
profile edit form

Do not prematurely push every keystroke to global state.

Use local state unless sharing or persistence is required.

Derived State

Derived state can be computed from existing state.

Examples:

completed count
progress percentage
current batch
filtered question list
is submit disabled

Avoid storing derived state separately unless there is a performance or synchronization reason.

Duplicated derived state causes drift.

Optimistic State

Optimistic updates make UI feel fast.

Use them for:

mark complete
like
save small preference
rename item
toggle flag

But define rollback behavior.

If the server rejects the mutation, the UI must recover clearly.

Realtime State

Realtime state needs ordering and recovery.

Ask:

what is the initial snapshot?
what updates stream in?
how are duplicates handled?
what happens after reconnect?
who wins conflicts?

Realtime is state synchronization, not just sockets.

Interview Example

If asked, "Design state for a large filterable dashboard," answer:

filters and sort in URL
table data as server state
selected rows as local UI state
edit form as form state
bulk action as mutation state
derived counts computed from response
permissions from server state

That shows ownership clarity.

Common Mistakes

Common mistakes include:

putting everything in global state
duplicating server state locally
not using URL state for shareable filters
storing derived state unnecessarily
forgetting rollback for optimistic UI
mixing draft state with persisted state
not modeling permissions
not planning realtime recovery

Senior-Level Framing

The senior framing:

"I model state by ownership and lifecycle. Once I know who owns the truth, how long it lives, who needs to read it, and how it changes, the state library decision becomes much easier."

Practice Prompt

Model state for Learning Studio cloud progress:

question completion
seconds spent
scroll depth
batch progress
offline updates
multi-device sync
reset page progress

Classify each as server, URL, local, draft, derived, optimistic, or persistent client state.

Final Mental Model

State architecture is not about where to put variables.

It is about ownership, lifecycle, sharing, persistence, and recovery.