Design question: Distributed session management for McpStreamableServerSession

[wankang189]

Background

In the model-context-protocol server implementation,
McpStreamableServerSession is currently managed as an in-memory object
(typically stored in a ConcurrentHashMap inside the transport provider).

This works well in a single-node deployment.
However, in a multi-node / distributed MCP server cluster, this causes
session lookup failures when requests are routed to different nodes.

Additionally, McpStreamableServerSession is not serializable, and it also
contains streaming primitives (SSE, Flux, sinks), which makes it difficult to
store in external systems like Redis.

---

Current Challenges

• Session state is bound to a single JVM instance.
• Load balancers may route subsequent requests to another node.
• McpStreamableServerSession cannot be persisted or transferred.
• SSE streaming introduces a strong coupling between session and node.

---

Questions

1. Is sticky-session at the gateway (Nginx / Ingress) the officially
   recommended deployment model for MCP servers?

2. Is there any plan to provide:

   • A pluggable SessionStore / SessionRepository abstraction?
   • Or a distributed session management API?

3. Would it be acceptable (by design) to:

   • Only externalize lightweight session metadata (sessionId, nodeId, clientId),
   • While keeping the streaming channel strictly local?

4. Do you envision MCP servers supporting:

   • Horizontal scaling with session migration?
   • Or is the protocol intentionally designed around connection-affinity?

---

Our Current Workaround

• We currently rely on gateway sticky sessions to keep requests on the same node.
• We are also experimenting with storing session routing metadata in Redis:
  sessionId -> nodeId, but keeping the streaming object in-memory.

---

Expected Capabilities

We hope to better support:

• Horizontal scaling of MCP servers
• Failover awareness
• Stable multi-node session routing

Any guidance on the official design direction would be greatly appreciated.
Thanks!

[quaff]

It's duplicate of #274

[wankang189]

It's duplicate of #274
Thanks for the clarification and for linking the duplicate issue! 🙏
We’ve now switched to the stateless mode, and it has successfully resolved our distributed session and scaling concerns. The behavior now aligns well with our expectations for horizontal scaling and failover.

Appreciate the guidance and the great work on the project! 🚀