Best architecture for large ERP app with 500+ endpoints across many modules

[BentolhodaAhmadi]

Hi,

I have a large ERP application with many modules:
general, warehouse, treasury, accounting, etc.

Previously I had one createApi per endpoint (~500 instances) which caused
the stack overflow bug reported in
#5285 #5279
#5283

I also opened a related issue here: #5285

After feedback from phryneas and markerikson on that issue,
I understand the correct approach is fewer createApi instances.

My current proposed architecture:
One createApi per module (~20-30 instances),
each containing 50-250 endpoints inside.

All modules are combined into one shell store:

const mergeReducerStore = {
  ...sharedCommonAppsReducerStore,
  ...accountingReducerStore,
  ...treasuryReducerStore,
  ...generalReducerStore,
  ...sharedServiceReducerStore,
      // ...other modules
};
const mergeMiddlewareStore = [
  ...sharedCommonAppsMiddlewareStore,
  ...accountingMiddlewareStore,
  ...treasuryMiddlewareStore,
  ...generalMiddlewareStore,
  ...sharedServiceMiddlewareStore,
      // ...other modules
];

export const store = configureStore({
  reducer: mergeReducerStore,
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware()
      .prepend(
        listenerMiddleware.middleware,

        // storesSharedServiceApi.middleware,
      )
      .concat(mergeMiddlewareStore)
      .concat(rtkQueryErrorLogger),
});

My questions:

1. Is "one createApi per module" the recommended pattern for large enterprise apps?
   Or should I go further and use a single createApi for everything?

2. With ~20-30 createApi instances, am I still at risk of hitting
   the stack overflow issue from Maximum call stack size exceeded with 500+ createApi instances, but works fine with same number of endpoints under single createApi #5285 RTK Query middleware self-registration can overflow the call stack with many createApi middlewares #5279?

3. Regarding invalidateTags:
   If one module api has 100+ tagTypes, when I call invalidateTags(['VoucherList']),
   does RTK Query only process queries that provide that specific tag?
   Or is there a performance cost to scanning all tags in the same api instance?

4. Does RTK Query do any work per-endpoint on every action dispatched,
   or only for active/subscribed queries?

Thank you.

[yudin-s]

I would go further than “one createApi per module” and make the split based on API/runtime boundaries, not UI modules.

For an ERP, a good target is usually:

• one shared/base API per backend origin + auth/cache policy
• inject endpoints from feature modules with api.injectEndpoints
• use tags as the cross-feature invalidation contract

That gives you one middleware/reducer for a large logical backend, while still letting modules own their endpoint definitions.

Example shape:

// services/baseApi.ts
export const baseApi = createApi({
  reducerPath: 'api',
  baseQuery,
  tagTypes: ['VoucherList', 'WarehouseItem', 'Account'],
  endpoints: () => ({}),
})

// accounting/api.ts
export const accountingApi = baseApi.injectEndpoints({
  endpoints: (build) => ({
    getVouchers: build.query<..., ...>({
      query: ...,
      providesTags: ['VoucherList'],
    }),
  }),
})

For your questions:

1. 20-30 APIs is much better than 500, but if they all hit the same backend and share auth/cache behavior, a single base API with injected endpoints is usually cleaner.
2. Each createApi adds its own reducer and middleware. 20-30 may work, but it is still avoidable overhead if the APIs are artificial module boundaries.
3. invalidateTags(['VoucherList']) only refetches active queries whose provided tags match, but RTK Query still has to process invalidation within that API slice. Keeping related tags in one API is normal.
4. Each API middleware sees dispatched actions. That is the main reason hundreds of createApi instances become painful. Fewer API slices means less middleware fan-out.

So I would use “single base API + endpoint injection” by default, then create separate APIs only for genuinely separate backends or incompatible cache/auth behavior.