These are the patterns that survive code review because each one looks like ordinary code. They only become leaks because of the fact from the overview: plugins and setup() run again for every SSR request inside a process that never restarts. Learn the table as a checklist you can run over a diff; the sections after it expand the ones that turn up most often in a layer's server code.

The catalogue

How it works

1 — Module-scope mutable state

The canonical leak, and the one interviewers use as a warm-up. It is also the security bug, because request two reads what request one wrote.

// module scope in the server bundle = one array for the whole process
const seen: unknown[] = []
let currentUser: User | null = null

export default defineNuxtPlugin(async (nuxtApp) => {
  seen.push(nuxtApp)                       // retains every request's Vue app
  currentUser = await $fetch('/api/me')    // request 2 can read request 1's user
  nuxtApp.provide('user', currentUser)
})

export default defineNuxtPlugin(async () => {
  // useState lives on this request's nuxtApp and is serialised into this response only
  const user = useState<User | null>('auth:user', () => null)
  user.value = await $fetch('/api/me')

  if (import.meta.server) {
    // per-request counters belong on the event, not on the module
    const event = useRequestEvent()
    if (event) event.context.audit = { renderedAt: Date.now() }
  }
})

The rule generalises: runtime code in a layer or module has no module-scope mutable state. const holding a frozen config object is fine. A Map, an array, a let, or a ref() is not, unless you are deliberately building a process-level cache — in which case see #4.

2 — Listeners registered per request

nitroApp.hooks.hook() returns an unsubscribe function, and calling it inside a request handler means you add a listener on every request that then holds that handler's closure — including its event.

export default defineEventHandler(async (event) => {
  const nitroApp = useNitroApp()

  // a new listener every request, each closing over this event
  nitroApp.hooks.hook('afterResponse', () => {
    track('report', event.path)
  })

  return buildReport(event)
})

export default defineNitroPlugin((nitroApp) => {
  // registered once for the process; the event arrives as an argument
  nitroApp.hooks.hook('afterResponse', (event) => {
    if (event.path.startsWith('/api/report')) track('report', event.path)
  })
})

3 — Timers started during SSR

export default defineNuxtPlugin(() => {
  // ⚠ on the server this creates one interval per request, forever
  setInterval(() => refreshFeatureFlags(), 30_000)
})

Rename the file to app/plugins/poll.client.ts and the problem disappears, because the plugin no longer exists in the server bundle. If the value genuinely has to refresh on the server, refresh it from a Nitro plugin (one interval per process) and call unref/clearInterval in the close hook — or better, cache it with a TTL and let the next request refill it.

4 — Unbounded caches and cache keys

Nitro's defineCachedEventHandler defaults its key to the request path plus query. Include a cache-buster, a session id or a ?t= timestamp and every request becomes its own cache entry.

export default defineCachedEventHandler(async (event) => {
  const { q, t } = getQuery(event)          // `t` is a random cache-buster
  return search(String(q ?? ''))
}, { maxAge: 60 })                          // key includes every query param

export default defineCachedEventHandler(
  async (event) => {
    const { q } = getQuery(event)
    return search(String(q ?? '').trim().toLowerCase().slice(0, 64))
  },
  {
    name: 'search',
    maxAge: 60,          // seconds fresh
    staleMaxAge: 300,    // seconds served stale while revalidating
    // the key is the ONLY thing that can grow: normalise it and bound its shape
    getKey: (event) => {
      const q = String(getQuery(event).q ?? '').trim().toLowerCase().slice(0, 64)
      return q || 'empty'
    },
  },
)

The same reasoning applies to the hand-rolled version. If you must keep an in-process cache, use lru-cache with an explicit max and ttl rather than a bare Map, and in production point Nitro's cache storage at Redis or KV so the memory is someone else's problem and survives a restart.

8 — Streams and abandoned upstream work

Buffers show up in external/arrayBuffers, not heapUsed, so this class of leak is invisible if you only watch the JS heap.

export default defineEventHandler(async (event) => {
  const controller = new AbortController()
  // when the browser disconnects, stop the upstream request instead of finishing it
  event.node.req.on('close', () => controller.abort())

  const res = await fetch(upstream, { signal: controller.signal })
  if (!res.ok) {
    await res.body?.cancel()   // an unconsumed body keeps its buffers alive
    throw createError({ status: res.status })
  }
  return res
})

The rest of the table follows the same three shapes. #5, #6 are "an object that should have been per-request was created once": an effectScope() you never stop, a createPinia() at module scope instead of inside the plugin, an Apollo or TanStack QueryClient shared by every user. #7, #9, #10 are "a process-lifetime container holding request objects": a Map of rendered HTML filled from render:response, a Map<requestId, ctx> whose delete is skipped on the error path, a defineCachedFunction whose arguments close over event. #11, #12, #13 are build-time and dev-time: a module that spawns a watcher or child process without nuxt.hook('close', …), a nuxt.hook registered inside a builder:watch callback so listeners double on every rebuild (use hookOnce), and a prerender collector that accumulates across ten thousand routes.

Exercise

Be able to say