Client-Side State Architecture for Large Apps

The plain-language idea

Every piece of state in a frontend app falls into one of three categories, and the category should drive where and how it's stored — not habit, not whatever's already in the codebase.

• Local / UI state — a dropdown's open/closed flag, a form input's current value before submit, whether a modal is visible. It belongs to one component (or a tight cluster of them) and nothing outside that area needs to read it. This is useState's home turf; reaching for a global store here is pure overhead.
• Shared / client state — a shopping cart's contents, a theme preference, the currently-selected filters on a dashboard. Multiple, possibly distant components need to read or write it, but it's still purely client-owned — nothing on a server is the source of truth for it.
• Server / cache state — data fetched from an API: a user's profile, a product catalog, a list of orders. This is the category most designs get wrong by treating it like shared client state, when it actually has different needs entirely: it can go stale (the server's copy may have changed since it was fetched), it needs refetching and invalidation logic, and it can be loading or erroring in ways a plain client value never is.

Naming that third category explicitly, out loud, is one of the highest-signal moves in a system design interview — it's the distinction that separates "I'll put everything in Redux" from an answer that actually reflects how modern apps are built.

See it in a real thing: a dashboard with a data table

Say the prompt is "design the state for a dashboard listing a company's orders, with client-side filters and sorting." A shallow answer reaches for one big store holding everything. A stronger answer separates it: the fetched order list is server state — it needs a fetch, a loading state, and a way to know if it's stale after a mutation elsewhere in the app. The currently selected filter and sort column are shared client state — no server round-trip needed, but shared between the filter bar and the table. Whether a single row's detail panel is expanded is local UI state, scoped to that row.

Once server and client state are pulled apart, the shape of the client state itself becomes its own decision: nested (denormalized) versus normalized. A nested shape mirrors the API response directly — an array of order objects, each with its full customer object embedded — and is the simplest thing to reach for first. It breaks down the moment the same entity appears in more than one place: update a customer's name in the order list and in a currently-open detail view, and now there are two independent copies that can drift out of sync unless every update site remembers to touch both. A normalized shape stores each entity once, keyed by id, with everything else referencing it by that id — updating the customer once updates every place that renders it. The cost is real: normalizing takes upfront structuring work and makes reads slightly less direct (a lookup instead of an inline value), which is exactly why it's a tradeoff worth naming rather than a default to reach for everywhere.

What people usually miss

Watch out

• Treating fetched API data as ordinary client state is the single most common architectural mistake in this space. It skips staleness and invalidation concerns entirely, which surface later as "why does this screen show old data" bugs instead of being designed for up front.
• The classification is the actual skill being tested, not the library name. An interviewer asking "how would you manage state here" wants to hear local/shared/server reasoning, not a Redux-versus-Zustand debate — that's a separate, narrower question this track covers on its own.
• Normalization is a decision to make deliberately, not a default. A small, rarely-duplicated dataset is often fine denormalized; reaching for full normalization everywhere is its own kind of over-engineering.
• "Shared" doesn't automatically mean "global." A cart shared between three sibling components can often live in state lifted to their common parent — a full app-wide store isn't a prerequisite for state to count as shared.

Why this matters in interviews

"How would you structure the state for this feature?" is one of the most frequently asked frontend system design questions, and the strongest signal a candidate can give is correctly sorting a prompt's state into local/shared/server categories before naming a single tool.