You ship a Next.js-style SSR app with a global user store. A month later, a user files a bug: "I logged in and saw someone else's profile." You can't reproduce it locally. Production logs are useless. The session cookie looks fine. What happened: your global store is a singleton on the server. Under concurrent requests, one request's setUser() wrote to the same object another request was reading. The second user hit a warm server, got a hydration payload containing the first user's data, and saw it for a split second before React reconciled. This is the SSR state management trap. It's one of the oldest footguns in server rendering, and almost every framework makes it possible. In this post: how it happens at the module level, how Pareto 's defineStore and defineContextStore address it, and the decision rule for which one to use. Why global state leaks across requests on the server In the browser, your app is one process per user.…