Key Takeaways
- Scale MCP without sticky sessions: store state in Redis/Postgres, add a gateway, and use Streamable HTTP.
- Your Claude Code MCP servers will survive container restarts and load balancers.
What Changed — MCP Session Architecture Is Moving to Stateless, Web-Native Design
Claude Code users who run MCP servers for multi-user agent workflows have a scaling problem. A local MCP server keeps session state in memory using a simple Map. That works on your laptop. In production, behind a load balancer with multiple instances, autoscaling, and container restarts, that in-memory state disappears when the next request lands on a different server.
The industry is shifting MCP from "one client talks to one remembered server" toward a web-native architecture. The key insight: session state is data, not process memory. This isn't about removing sessions — it's about storing them externally so any healthy server instance can handle any request.
What It Means For You — Concrete Impact on Your Claude Code MCP Servers
If you deploy MCP servers for Claude Code (e.g., custom tools for code analysis, deployment, or database queries), you've likely encountered:
- Tool calls failing because a container restarted
- Uneven load distribution from sticky sessions
- Fragile blue/green deployments where state gets lost
The fix is straightforward: move session metadata (tenant ID, user ID, allowed tools, budget limits, workflow checkpoints) to Redis, Postgres, or DynamoDB. The server process executes tool calls, but durable workflow truth lives outside it.
Try It Now — Commands, Config, and Patterns to Scale Your MCP Servers
1. Add a Gateway Layer
Don't expose every MCP server directly. Use a lightweight gateway (or API gateway) that handles:
- Authentication
- Tenant lookup
- Rate limits
- Session ID creation
- Routing to the right MCP service
2. Use Streamable HTTP Transport
For hosted MCP servers, prefer Streamable HTTP over stdio. Each client message is an HTTP POST, and servers can return JSON or stream with SSE. Standard load balancers understand the traffic shape.
POST /mcp
Accept: application/json, text/event-stream
Mcp-Session-Id: sess_123
{ "jsonrpc": "2.0", "id": 7, "method": "tools/call", "params": {...} }
3. Store Session State Externally
Redis for hot state:
type McpSession = {
sessionId: string;
tenantId: string;
userId: string;
allowedTools: string[];
budgetRemaining: number;
createdAt: number;
expiresAt: number;
lastEventId?: string;
status: "active" | "cancelled" | "expired";
};
Postgres for durable audit history:
create table mcp_tool_calls (
id uuid primary key,
session_id text not null,
tenant_id text not null,
user_id text not null,
tool_name text not null,
input jsonb,
output jsonb,
duration_ms integer,
created_at timestamptz default now()
);
4. Modify Your MCP Server to Check External State
Instead of const sessions = new Map(), your server should:
- On startup: connect to Redis/Postgres
- On tool call: look up session by ID from external store
- On write: update session state atomically
This ensures any healthy instance can handle any request, regardless of which server started the session.
Source: dev.to
