State Management at Scale: Comparing Zustand, Redux Toolkit, and React Query

Remote data has properties that global stores model badly: it can be stale, it must deduplicate concurrent requests, it needs retry and background refetch, and it must be invalidated by mutations. React Query handles these natively, along with request cancellation and optimistic updates with rollback.

The practical rule is that no fetched entity should be copied into a client store. Duplication creates two sources of truth and a synchronization bug that surfaces months later. Derive from the cache; do not mirror it.

Zustand is minimal: a hook-based store with selector subscriptions, negligible boilerplate, and easy slicing. It suits teams that want local reasoning and few conventions, and it scales well when stores stay small and domain-scoped.

Redux Toolkit brings enforced structure — actions, reducers, middleware, and a time-travel devtools story. That structure pays for itself in large organizations where many teams touch the same state and where auditable transitions matter. It costs more ceremony per change, which is a real tax on small teams.

A common healthy architecture is React Query for all server data, Zustand or Redux Toolkit for a deliberately small set of cross-cutting client concerns such as theme, layout, and selection, a dedicated form library for form state, and URL search params for anything that should survive a refresh or be shareable.

Whichever client library is chosen, subscribe with narrow selectors rather than whole-store reads, keep derived values memoized, and colocate state as close to its consumer as possible. Most performance problems attributed to a library are actually subscription breadth problems.