What drives your choice between Zustand and Redux Toolkit at scale?

WHAT THIS TESTS: The interviewer wants to see architectural judgment, not library fandom. They are checking if you can map tool characteristics to team size, application complexity, and maintenance horizon. Senior engineers should defend a choice with concrete trade-offs rather than personal preference.

A GOOD ANSWER COVERS: First, bundle size and performance. Zustand adds roughly one kilobyte and uses a pub-sub model outside React's context, avoiding unnecessary re-renders with minimal effort. Redux Toolkit is larger but pays for itself when you need built-in normalization, caching, and predictable update patterns. Second, boilerplate and developer experience. Zustand requires almost no setup; you create a store hook and consume it anywhere. Redux Toolkit demands more ceremony with slices, reducers, and configureStore, but that ceremony enforces consistency across dozens of modules and engineers. Third, debugging and ecosystem. Redux DevTools offers time-travel debugging, action replay, and state diffing out of the box, which is invaluable in production incident response. Zustand's DevTools integration exists but is thinner and relies more on manual logging or external wrappers. Fourth, async logic and middleware. Redux Toolkit includes RTK Query and createAsyncThunk for caching, deduplication, and background refetching. Zustand leaves async patterns entirely to the developer, which means more flexibility but also more inconsistency if multiple authors invent their own data-fetching layers.

COMMON WRONG ANSWERS: A red flag is claiming Zustand replaces Redux in every scenario or that Redux is always necessary for large apps. Another mistake is ignoring team dynamics; a team of twenty engineers often benefits from Redux Toolkit's strict conventions more than from Zustand's freedom. Saying bundle size is the only metric is also weak, since a few kilobytes rarely matter if the alternative prevents a class of state bugs.

LIKELY FOLLOW-UPS: The interviewer might ask how you would migrate from one to the other incrementally, or how you handle server-state hydration with each. They may also probe whether you would combine them, using Zustand for ephemeral UI state and Redux Toolkit for global server-state caches, and how you would prevent circular dependencies or double sources of truth.

ONE CONCRETE EXAMPLE: Imagine a multi-tenant dashboard with fifty engineers. Global filters, user permissions, and fetched entity caches cross many domains. Redux Toolkit shines here because RTK Query normalizes cache keys, createSlice enforces immutable updates, and new hires can read the folder structure and know exactly where to add a feature. Conversely, a three-person team building a creative canvas tool with lots of transient pointer and zoom state would move faster with Zustand's minimal API, avoiding the indirection of actions and reducers for every minor interaction.