DEV Community

Cover image for Frontend System Design: How do you structure Redux for a 200+ screen enterprise application?
ZeeshanAli-0704
ZeeshanAli-0704

Posted on • Edited on

Frontend System Design: How do you structure Redux for a 200+ screen enterprise application?

#architecture #javascript #react

🏗️ How to Structure Redux for Large-Scale Apps (200+ Screens)

A practical, enterprise-ready Redux architecture guide with real examples.

📌 Table of Contents

  1. Why Redux Structure Matters
  2. Redux Explained with a Simple Analogy
  3. Goals of a Good Redux Architecture
  4. Recommended Redux Folder Structure (200+ Screens)
  5. Why This Structure Works for Enterprise Apps
  6. Clean Redux Store Setup
  7. Feature Level Slice Example (Users)
  8. How Features Stay Self Contained
  9. Where Should Async API Calls Go?
  10. Enterprise Redux Rules You Must Follow
  11. Can a Feature Have Multiple Slices?
  12. Combining Multiple Slices Inside a Feature
  13. Final Redux State Shape
  14. When Should You Split Slices?
  15. Final Summary

Why Redux Structure Matters

When your app grows to 100–200+ screens, Redux can either:

  • ✅ Become your biggest productivity booster
  • ❌ Or turn into an unmaintainable mess

Bad Redux structure leads to:

  • Huge reducers
  • Tight coupling between features
  • Difficult debugging
  • Fear of adding new screens

A good structure, on the other hand, makes your app:

  • Easy to scale
  • Easy to debug
  • Easy to onboard new developers

Redux Explained with a Simple Analogy

Think of your application as a big office building.

  • 🏢 Building → Your application
  • 🧑‍💼 Building Manager → Redux Store
  • 🏬 Each Floor → A large feature (Users, Payments, Orders)
  • 🚪 Each Room → A screen/page
  • 🗄️ File Cabinets → Redux slices

The Golden Rule

Files from one floor NEVER mix with another floor.

Each feature manages its own data.
The store only connects features — it doesn’t control their internal logic.

Goals of a Good Redux Architecture

A solid Redux setup should:

  • 🎯 Make feature state easy to find
  • 🐞 Make bugs easy to trace
  • 🚀 Allow easy scaling
  • ♻️ Encourage reuse of shared logic
  • 🧠 Keep mental overhead low

Recommended Redux Folder Structure (200+ Screens) 

/src
 ├── app/
 │    ├── store.js
 │    └── rootReducer.js
 │
 ├── features/
 │    ├── users/
 │    │    ├── api/
 │    │    │   └── usersApi.js
 │    │    ├── components/
 │    │    │   └── UserTable.jsx
 │    │    ├── pages/
 │    │    │   └── UserListPage.jsx
 │    │    ├── slices/
 │    │    │   └── usersSlice.js
 │    │    └── index.js
 │    │
 │    ├── payments/
 │    ├── orders/
 │    ├── dashboard/
 │    └── ...
 │
 ├── shared/
 │    ├── slices/
 │    │    ├── authSlice.js
 │    │    ├── uiSlice.js
 │    │    └── appConfigSlice.js
 │    ├── hooks/
 │    └── utils/
 │
 ├── components/   // truly reusable UI
 └── index.js
Enter fullscreen mode Exit fullscreen mode

Why This Structure Works for Enterprise Apps

✔ Feature Isolation

Each feature contains everything it needs:

  • slices
  • pages
  • components
  • API logic

Deleting or moving a feature becomes trivial.

✔ Clean Store

The store stays simple and readable:

{
  users,
  payments,
  orders,
  auth,
  ui
}
Enter fullscreen mode Exit fullscreen mode

No feature knows about another feature’s internals.

✔ Shared Logic Lives in /shared

Only truly global concerns go here:

  • authentication
  • global loaders
  • modals
  • app configuration

✔ Infinite Scalability

Adding a new feature never breaks existing ones:

features/newFeature/
  ├── slices/
  ├── pages/
  ├── components/
  └── api/
Enter fullscreen mode Exit fullscreen mode

Clean Redux Store Setup

app/store.js 

import { configureStore } from "@reduxjs/toolkit";
import rootReducer from "./rootReducer";

export const store = configureStore({
  reducer: rootReducer,
});
Enter fullscreen mode Exit fullscreen mode

app/rootReducer.js 

import { combineReducers } from "@reduxjs/toolkit";

import usersReducer from "../features/users";
import paymentReducer from "../features/payments";
import orderReducer from "../features/orders";

import authReducer from "../shared/slices/authSlice";
import uiReducer from "../shared/slices/uiSlice";

export default combineReducers({
  users: usersReducer,
  payments: paymentReducer,
  orders: orderReducer,
  auth: authReducer,
  ui: uiReducer,
});
Enter fullscreen mode Exit fullscreen mode

Feature Level Slice Example (Users) 

import { createSlice } from "@reduxjs/toolkit";

const initialState = {
  list: [],
  loading: false,
};

const usersSlice = createSlice({
  name: "users",
  initialState,
  reducers: {
    setUsers(state, action) {
      state.list = action.payload;
    },
    setLoading(state, action) {
      state.loading = action.payload;
    },
  },
});

export const { setUsers, setLoading } = usersSlice.actions;
export default usersSlice.reducer;
Enter fullscreen mode Exit fullscreen mode

How Features Stay SelfContained 

/features/users
 ├── slices/
 ├── api/
 ├── pages/
 ├── components/
 └── index.js
Enter fullscreen mode Exit fullscreen mode

Each feature behaves like a mini-application.

Where Should Async API Calls Go?

Option A: createAsyncThunk

✔ Centralized loading/error handling
✔ Good for enterprise workflows

Option B: RTK Query

✔ Caching
✔ Auto refetch
✔ Best for data-heavy apps

Option C: Custom Hooks

✔ Complex business rules
✔ Highly customized behavior

Enterprise Redux Rules You Must Follow

RULE 1: Never create one giant slice

One feature = one domain.

RULE 2: Pages never talk to Redux directly 

const users = useSelector(state => state.users.list);
const dispatch = useDispatch();
Enter fullscreen mode Exit fullscreen mode

RULE 3: Keep shared state minimal

Only:

  • auth
  • modals
  • loaders
  • notifications

RULE 4: Always use createSlice

Less boilerplate. Fewer bugs.

RULE 5: Features must stay isolated

No cross-feature imports.

Can a Feature Have Multiple Slices?

✅ YES — and it SHOULD for large features

Combining Multiple Slices Inside a Feature 

src/features/users/slices/
 ├── usersListSlice.js
 ├── userDetailsSlice.js
 ├── userPermissionsSlice.js
 └── userFiltersSlice.js
Enter fullscreen mode Exit fullscreen mode

Combine them in features/users/index.js 

import { combineReducers } from "@reduxjs/toolkit";

import list from "./slices/usersListSlice";
import details from "./slices/userDetailsSlice";
import permissions from "./slices/userPermissionsSlice";
import filters from "./slices/userFiltersSlice";

export default combineReducers({
  list,
  details,
  permissions,
  filters,
});
Enter fullscreen mode Exit fullscreen mode

Final Redux State Shape 

{
  users: {
    list: {},
    details: {},
    permissions: {},
    filters: {}
  },
  payments: {},
  orders: {},
  auth: {}
}
Enter fullscreen mode Exit fullscreen mode

Clean. Predictable. Scalable.

When Should You Split Slices?

Split when:

  • Slice exceeds 300–400 lines
  • Slice manages multiple screens
  • Slice mixes UI + domain logic
Slice Name Responsibility
usersList table, pagination
filters search, sorting
details profile page
permissions roles & access

Final Summary

🏆 Best Redux Structure for Large Apps

  • app/ → store & root reducer
  • features/ → one folder per domain
  • shared/ → truly global state
  • multiple slices per feature if needed
  • combine slices inside the feature

🎯 Result

  • Easy to scale
  • Easy to debug
  • Easy to onboard developers
  • Enterprise-ready architecture

More Details:

Get all articles related to system design
Hastag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali

Git: https://github.com/ZeeshanAli-0704/front-end-system-design

Top comments (0)