Next.js 15 App Router: Memory Leak Leading to OOM (Exit 137) in Production - Zustand Store Cleanup Issue

[vishwas-fab]

Summary

Hi everyone,

I'm experiencing a critical memory leak in production with Next.js 15.3.3 (App Router) that's causing OOM kills (Exit Code 137) on GKE. Looking for advice on proper cleanup patterns.

Environment:

• Next.js: 15.3.3
• Node: 20.5.0
• Deployment: GKE (Google Kubernetes Engine)
• State Management: Zustand
• Memory Limit: 3.5GB
• Heap Limit: 2GB (--max-old-space-size=2048)

The Problem:

Pods restart with Exit Code 137 (OOM kill) after 5-11 hours of runtime. The pattern is consistent and accelerating (was 11 hours, now down to 5 hours).

Symptoms:

• Memory grows steadily over time
• Restart count: 8 in last 24 hours
• Exit Code 137 every time
• Memory reaches 100% before kill

Architecture:

We have a property detail page (PDP) that:

1. Fetches data server-side via API call
2. Passes data to client component
3. Client component creates Zustand store
4. Store is module-level and persists across requests

Suspected Root Cause:

// src/app/pdp/pdpStores/pdpStores.ts
let apiStore: UseBoundStore<StoreApi<PdpApiState>> | null = null;

export const createPdpApiStore = (initialData, isLoggedIn) => {
  apiStore = create<PdpApiState>((set, get) => ({
    propertyDetailsData: initialData,  // Large object ~200KB
    checkoutDetailsData: null,
    // ... more state
  }));
  return apiStore;
};

// ❌ NO CLEANUP FUNCTION!

The Issue:

Each PDP page view creates a new store, but the old store reference persists in memory. With ~15,000 requests over 5-11 hours, this accumulates to 3GB+.

Questions:

1. Is this the correct pattern for Zustand in Next.js App Router? Should stores be module-level or created differently?

2. How should I properly clean up Zustand stores in SSR context? I'm thinking:

export const cleanupPdpApiStore = () => {
  if (apiStore) {
    apiStore.setState({
      propertyDetailsData: null,
      checkoutDetailsData: null,
      // ... clear all state
    });
    apiStore = null;
  }
};

Then call this in a useEffect cleanup:

useEffect(() => {
  return () => {
    cleanupPdpApiStore();
  };
}, []);

3. Are there better patterns for managing state in high-traffic SSR apps? Should I avoid module-level stores entirely?

4. Could Next.js caching be contributing? We're using output: 'standalone' and have fetch calls with default caching.

What I've Tried:

• ✅ Verified with heap snapshots (Zustand stores accumulating)
• ✅ Checked for event listener leaks (found 169 without cleanup)
• ✅ Disabled image optimization (unoptimized: true)
• ✅ Monitored with health endpoint (memory climbs steadily)
• ❌ Cannot reproduce locally (leak is too slow)

Additional Context:

• High traffic site (~1,500-3,000 req/hour)
• PDP pages are most visited
• API responses are 100-500KB
• Using standalone output mode
• Server-side rendering for SEO

Any advice on:

• Proper Zustand cleanup in App Router
• Memory management best practices for high-traffic Next.js apps
• Alternative state management patterns
• Debugging techniques for slow memory leaks

Thanks in advance!

Additional information

No response

Example

No response

[icyJoseph]

Mmm wait what is happening here?

let apiStore: UseBoundStore<StoreApi<PdpApiState>> | null = null;

export const createPdpApiStore = (initialData, isLoggedIn) => {
  apiStore = create<PdpApiState>((set, get) => ({
    propertyDetailsData: initialData,  // Large object ~200KB
    checkoutDetailsData: null,
    // ... more state
  }));
  return apiStore;
};

Doesn't this mean apiStore is effectively shared by all users? This feels weird, where did you get this pattern from? I guess one could say, well do apiStore = null before assigning a new one, but it does feel sketchy, surprised you don't have other kind of bugs... Did you do this because you want to re-use the apiStore in other sub trees etc, like avoiding prop drilling with a global singleton?

I think you need defer initializing the store until you are fully client side. Just send the initial inputs to the client, anything but the global singleton.