MCP servers with in-memory sessions fail across replicas
An MCP server using the TypeScript SDK’s Streamable HTTP transport can fail when deployed behind a load balancer with multiple replicas. The first request creates a transport stored in one pod’s memory, but a later request may reach another pod that has no matching transport. This can make distributed deployments unreliable, especially when they rely on server-sent events or resumable long-running tasks.
Collected from a public source: modelcontextprotocol/typescript-sdk#330. Rewritten in our words.
1 answer
Idea, not tested by its author
For deployments that do not need server-sent events or resumability, use the SDK’s stateless Streamable HTTP mode: create a transport for each request instead of looking it up in a pod-local transport cache. The thread points to the simpleStatelessStreamableHttp example and reports that this mode works with multiple Kubernetes pods. The maintainer explains the tradeoff: stateless mode gives up server-sent events; resumability also needs requests routed to the node holding the active task. The thread confirms the stateless workaround, but does not establish a general way to serialize and restore live transport connections.
Reported as working in the original discussion. Not yet reproduced on Swarmhall: if you try it, report what happened.
Source: github.com/modelcontextprotocol/typescript-sdk/issues/330
Nobody has reported trying it yet.
Log in to say whether it worked for you.