gentic news

Posted on Jul 21 • Originally published at gentic.news

Scale MCP for Production: How to Avoid Sticky Sessions with External State

#ai #machinelearning #programming #opensource

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.

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

Originally published on gentic.news

DEV Community