Q176: Server State, Client State and Cache Ownership
What Interviewers Want To Evaluate
This question checks whether you can classify state correctly in a React application. Interviewers want local UI state, server state, derived state, URL state, persisted state, cache ownership, invalidation, stale data, optimistic updates, and Next.js Server Component boundaries.
Senior answers should avoid treating all state as one bucket.
Short Interview Answer
Client state is owned by the browser UI, such as open menus, current input text, selected tabs, and temporary drafts. Server state is owned by the backend, such as users, products, permissions, and dashboard data. Server state needs fetching, caching, invalidation, refetching, optimistic updates, and error handling. Client state needs placement, reset rules, persistence decisions, and accessibility behavior. Good architecture separates ownership before choosing tools.
Detailed Interview Answer
React applications contain multiple state categories.
local UI state
component state
form state
URL state
server state
derived state
external store state
persisted browser state
The mistake is managing them all the same way.
Local UI State
Local UI state belongs near the component that uses it.
Examples:
is menu open
active tab
hovered row
expanded accordion
input draft
modal step
temporary checkbox selection
If only one component subtree cares, keep it close.
Server State
Server state is remote, shared, and authoritative.
Examples:
current user profile
product list
notification count
permissions
invoice data
feature config from backend
dashboard metrics
Server state can become stale and needs a cache strategy.
Derived State
Derived state is calculated from other state.
Bad:
const [fullName, setFullName] = useState(first + " " + last);
Better:
const fullName = `${first} ${last}`;
Do not store derived values unless calculation is expensive, asynchronous, or needs a snapshot.
URL State
URL state is useful when state should be shareable or restorable.
search query
filters
sort order
page number
selected dashboard view
deep-linked tab
URL state improves reload, sharing, and navigation behavior.
It is not ideal for sensitive or very large state.
Cache Ownership
Server state cache ownership should be explicit.
Ask:
who fetched this data
who can invalidate it
how stale can it be
is it user-specific
is optimistic update allowed
what happens on mutation
what happens offline
what is the retry policy
Cache behavior is part of product correctness.
React Query Style Model
Server-state libraries commonly model:
query key
query function
stale time
cache time
refetch triggers
mutation lifecycle
optimistic update
invalidation
retry
error state
This is different from local component state.
Next.js App Router Model
In Next.js, Server Components can fetch data on the server and stream rendered UI.
Client Components can still manage:
interactive filters
optimistic mutations
pending form state
client-only widgets
external subscriptions
The boundary should follow ownership.
Common Mistakes
A common mistake is copying server data into local state and forgetting to sync it.
Another mistake is putting URL-shareable filters only in component state.
Another mistake is using global stores for small local UI state.
Another mistake is storing derived state and creating drift.
Another mistake is invalidating too broadly and causing unnecessary refetches.
Senior Trade-Offs
State tools are not interchangeable.
Context helps distribute stable dependencies.
External stores help with shared client state and granular subscriptions.
Server-state libraries help with remote cache lifecycle.
URL state helps with navigation and shareability.
Server Components help move data reads out of the browser.
Debugging Workflow
When state bugs appear:
identify the source of truth
classify the state category
check whether state is duplicated
inspect cache invalidation
check URL and navigation behavior
test mutation and rollback
test stale data after tab focus
test reload and back button
verify server authorization
Interview Framing
Start by classifying state. Then discuss ownership, cache behavior, URL state, derived state, mutation invalidation, and tool choice.
Revision Notes
Most React state problems are ownership problems before they are hook problems.
Key Takeaways
Choose state location and tooling by lifetime, authority, shareability, and invalidation rules.
Follow-Up Questions
- What is server state?
- What is local UI state?
- Why is derived state risky?
- When should state live in the URL?
- What does cache invalidation mean?
- Why is copying server data into local state dangerous?
- When is Context enough?
- When is an external store useful?
- How do Server Components affect state ownership?
- How do optimistic mutations fit?
How I Would Answer This In A Real Interview
I would classify the state first. Server data needs caching and invalidation, local UI state should stay near its owner, URL state should support navigation and sharing, and derived state should usually be calculated instead of stored. Then I would choose React, cache, URL, or server boundaries accordingly.