Almost every memory question an interviewer asks is really "do you know which lifetime this value is in?". A Nuxt app has three, they are nested, and code that looks identical behaves completely differently depending on which one it runs in. Get this table into muscle memory and the leak catalogues on the next two pages stop being lists to memorise and become consequences you can derive.

Know

• Process lifetime — the Node server, hours to days. Module-scope variables in the server bundle (everything at the top level of a server/ file, a Nitro plugin, or the server half of a universal plugin's module), Nitro plugins themselves, global caches, and listeners on process-lifetime emitters: process.on, timers, a database client, a message-bus connection. Owner: the Node process. Nothing here is ever collected while the server runs.
• Request lifetime — milliseconds. The h3 event, event.context, a fresh nuxtApp for every SSR request (a fresh Vue app, a fresh set of plugin runs, a fresh component tree), the useState store and the payload that will be serialised into the HTML, the unhead instance, the per-request Pinia instance. Owner: the request. All of it should be unreachable the moment the response is flushed.
• Client session — a browser tab, minutes to hours. Exactly one nuxtApp, created once by the client entry and alive until reload or close; its payload/useAsyncData cache, its plugin state, its router. Components mount and unmount below it on every route change. Owner: the tab.
• Universal plugins live in two lifetimes at once. The same file runs once per tab in the browser and once per request on the server. Every line has to be correct in both readings — this is why setInterval in a universal plugin is a leak and in a .client.ts plugin is fine.
• Module scope is not a lifetime, it is a trap door into the longest one. Top-level code in a server bundle runs once per process; top-level code in a client bundle runs once per tab. A const cache = new Map() in a file imported by both is two completely different objects with two completely different risk profiles.
• The deciding question: "who should still hold this after the response is sent?" Nobody → event.context or a local. This app instance → useState / nuxtApp.provide. The whole process, deliberately → a bounded cache with a key and a TTL, documented. There is no fourth answer.

The table

How it works

Two files that look similar and are not. The Nitro plugin body runs once; the event handler body runs per request:

// process lifetime: this body runs once, when Nitro starts
export default defineNitroPlugin((nitroApp) => {
  let requests = 0

  // registered once, for the life of the process — correct
  nitroApp.hooks.hook('afterResponse', () => { requests++ })

  // anything long-lived must also be tearable-down
  nitroApp.hooks.hookOnce('close', () => { console.log('served', requests) })
})

// request lifetime: this body runs for every request
export default defineEventHandler(async (event) => {
  // correct home for per-request data: dies with the event
  event.context.user = await resolveUser(event)
  return { name: event.context.user.name }
})

The universal plugin is the one to reason about out loud, because it is both lifetimes at once:

// ⚠ module scope. On the server this is ONE array for the whole process.
const buffer: unknown[] = []

export default defineNuxtPlugin((nuxtApp) => {
  // this callback runs once per tab in the browser, and once per SSR request in Node
  buffer.push(nuxtApp) // leaks every request's Vue app, forever

  if (import.meta.client) {
    // safe: the tab owns this, and it goes away with the tab
    setInterval(() => flush(), 10_000)
  }
})

The same intent, written so each value sits in the lifetime that should own it:

import { effectScope, shallowRef } from 'vue'

export default defineNuxtPlugin(() => {
  // client session: one buffer per tab, never one per request
  const buffer = shallowRef<unknown[]>([])

  // detached scope: no component owns this, so I own it and I can stop it
  const scope = effectScope(true)
  scope.run(() => {
    // VueUse registers its own cleanup on the active scope, so stopping it clears the timer
    useIntervalFn(() => flush(buffer.value), 10_000)
  })

  // one teardown for everything the plugin started (HMR would otherwise stack timers in dev)
  if (import.meta.hot) import.meta.hot.dispose(() => scope.stop())

  return { provide: { telemetry: { buffer } } }
})

Exercise

Be able to say