By Rahul — Google Frontend Engineer
As a Staff Engineer at Google, I’ve seen projects scale from "two guys in a garage" to hundreds of contributors. In that transition, the primary threat to a codebase isn't "slow code"—it’s cognitive overhead. When a developer can’t predict how a single click affects a distant part of the UI, the project is dying.
Redux is the "Big Iron" of frontend architecture. It is designed not for speed of writing, but for speed of understanding in massive systems.
1. The Real-World Stores: 5 Case Studies from the Trenches
I. UberEats: The "Dependency Hell" of Sagas
At Uber, the mobile-web platform was built on Redux-Saga. With over 100 Sagas and 60+ reducers, the team ran into a unique Staff-level problem: implicit execution order.
The Story: A developer would dispatch a
FETCH_USERaction, but three different Sagas would intercept it to fetch the user's profile, their past orders, and their active cart. Because these were all global, a change in the "Cart Saga" would accidentally break the "Profile Page" because of a shared loading flag.The Lesson: Uber moved toward Domain-Oriented Microservice Architecture (DOMA) on the frontend. They learned that Redux is powerful, but without Slice isolation, it becomes a global "spaghetti" of side effects.
II. WordPress Calypso: The Power of Selectors
WordPress.com’s entire dashboard (Calypso) is one of the world's largest Redux apps.
The Story: When they needed to refactor their entire backend API schema from a flat structure to a nested one, they didn't touch their UI components.
The Win: Because they used Reselect (Memoized Selectors), they only updated the logic in the selectors. The components continued to ask for
getUserDetails, completely unaware that the underlying Redux state shape had changed entirely. This is the definition of decoupled architecture.
III. The "Great Redux Deletion" (SaaS Story)
Many mid-sized startups (like those documented on Dev.to) reported deleting up to 70% of their Redux code in 2024–2025.
The Story: A team realized that most of their Redux store was just boilerplate for API calls:
FETCH_START,FETCH_SUCCESS,FETCH_ERROR.The Win: By migrating to React Query, they replaced 2,000 lines of Redux logic with 50 lines of hooks. They kept Redux only for a small "Global Draft" feature where a user could work on a document across multiple tabs.
IV. DoorDash: Handling High-Frequency Updates
DoorDash manages complex real-time states for orders, drivers, and restaurant statuses.
The Story: They faced performance bottlenecks where updating a single driver's GPS location caused the entire sidebar of 50 orders to re-render.
The Win: They used Normalizr to flatten their state. Instead of nesting orders inside restaurants, they kept
ordersandrestaurantsas separate flat maps linked by IDs. This allowed Redux to update one specific "Order ID" without touching the rest of the tree.
V. Netflix: The "Message Broker" Philosophy
Netflix uses a "One-way Action Stream" to keep their playback UI in sync with background telemetry.
The Story: Instead of components calling functions, they "emit" events to a global stream.
The Win: This allowed them to implement Time-Travel Analytics. They could take a bug report from a user, download the action log, and "replay" the user's entire session in their local Redux DevTools to see exactly where the state diverged.
2. Convincing the Staff: Why "Simple" Libraries Fail at Scale
Staff Engineers often push for Zustand or Context because they are "easier." Here is why you should push back (or lean in) for Enterprise work:
The "Governance" Argument
In a project with 50 engineers, "easy" is a liability.
Zustand is unopinionated. Engineer A might use nested objects; Engineer B might use flat state.
Redux Toolkit (RTK) enforces a pattern. It provides a paved road. You don't have to review the "architecture" of every PR because the library enforces it.
The "Middleware" Superpower
Redux is a Message Broker for the browser. No other library handles cross-cutting concerns as well:
Persistence:
redux-persistcan save specific slices to disk automatically.Syncing: You can sync state across browser tabs using
BroadcastChannelin a Redux middleware in 10 lines of code.Logging/Analytics: One middleware can listen to all "SUCCESS" actions and report them to Segment or Datadog without adding a single line of code to your components.
3. Redux Toolkit: The Modern Standard
If you aren't using Redux Toolkit (RTK), you aren't using Redux. Period.
TypeScript
// Modern Redux: The "Slice" Pattern
const orderSlice = createSlice({
name: 'orders',
initialState: ordersAdapter.getInitialState(),
reducers: {
// Immer allows "mutative" logic that stays immutable
addOrder: (state, action) => {
ordersAdapter.addOne(state, action.payload);
},
},
extraReducers: (builder) => {
// Responding to actions from OTHER slices (Global Sync)
builder.addCase(authActions.logout, (state) => {
ordersAdapter.removeAll(state);
});
}
});4. The Staff Engineer’s Decision Matrix
App Type | Recommended Stack | Why? |
Simple SaaS / Blog | Context + useState | Zero overhead, fast shipping. |
API-Heavy Dashboard | React Query + Zustand | 90% of state is just server cache. |
Complex Editor (Figma/Canva) | Redux Toolkit | Needs deep undo/redo and complex local logic. |
White-Label / Large Enterprise | Redux Toolkit | Governance, strict patterns, and team scale. |
5. Summary for the CTO
Redux is a Governance Tool: Use it when you need to enforce a "standard" across many teams.
Redux is not for Server State: Use React Query for APIs.
Redux is for Business Logic: If your app has complex rules (e.g., "If the user is in Germany and has a Pro account, show the VAT-adjusted price in the sidebar"), that logic belongs in a Redux Reducer, not a React Component.