`const cache = new Map()` at module scope runs once per instance, not once per deployment. That is the whole bug. When a request arrives, Vercel either hands it to a warm instance left over from recent traffic, or builds a fresh one: load the Node.js runtime, import every module the function depends on, run module-level initialization, then answer [4]. Each fresh instance gets its own empty Map [7].
A cache hit here depends on which instance answered, not on the key itself, and the caller cannot see that and the code cannot ask [16]. Requests arriving in a burst share a warm instance and see the stored value; the first request after an idle gap lands on a new instance and sees a miss [6][7]. According to the dev.to writeup, that is precisely what produced the inconsistent responses: a cache that existed in one instance and not another, both serving the same endpoint [8]. Three days went into looking for it in the query logic [3].
It worked in local development, which is the most expensive kind of working [9].
The counter version fails more quietly. Rate limiting in the same codebase tracked how many requests an IP had made in a rolling window, in memory [11]. Keep that counter at module scope and the enforced ceiling becomes the configured limit multiplied by the number of instances currently holding a counter [15]. Three live instances, three times the allowance. Traffic growth adds instances, so the limiter loosens exactly when you wanted it to bite, and it returns success the entire time.
For module-scope state to be safe here, two things have to hold: it is derivable from the deployment alone, and no request's correctness depends on an earlier request having run. A compiled regex qualifies. A database client handle qualifies. A lookup cache fails this test, because a miss changes the response and not just its latency. A counter fails it too, because the count is the response.
Scope note, because this is one developer's first-hand account of one JSON API deployed inside Next.js API routes [1][17]. There are no instance counts in it and no measured warm window. The post says Vercel keeps instances warm for a period after their last request [6]. That period is the parameter you would need to design around, and it is not one you set. Which is the actual statement the platform is making: the same Map on a long-running Express process behaves as expected because the process outlives the request [10], and serverless sells you the opposite guarantee.
