MCP server — stateless instances, external session state, durable history

Run it

npm install
npm run dev          # starts the server on :3000
npm run simulate     # in another terminal: runs the traffic simulation

Files

• src/session-store.ts — the "hot" tier. Stands in for Redis: active session state, TTL-expired. Swap the internals for ioredis later; the interface (get/create/update) doesn't change.
• src/history-store.ts — the "durable" tier. Stands in for Postgres: append-only conversation log, idempotency-key guarded so client retries under load never duplicate a turn.
• src/mcp-instance.ts — the actual MCP server: registers a chat tool that resolves session_id → cache-or-rebuild-from-history → append turn → reply → update session.
• src/server.ts — Express + Streamable HTTP transport. Note the comment block distinguishing MCP protocol session (transport handshake, kept in an in-memory Map, dies with the process) from application conversation session (your data, lives in the stores above, survives a restart/rescale).
• src/simulate-traffic.ts — a real MCP client (not curl) that (a) runs one user through several turns on the same session to prove continuity, and (b) fires 25 concurrent new conversations to prove the server handles concurrent load without cross-talk.

What's simulated vs. real here

Real: the MCP protocol handshake, tool registration/invocation, the client↔server wire format, concurrency handling.

Simulated (by design, so you can run this with zero external infra): SessionStore/HistoryStore are in-memory. To go to production:

1. Replace Map in session-store.ts with an ioredis client — same method signatures.
2. Replace the array in history-store.ts with pg (or Drizzle/Prisma) queries against a turns table — same method signatures.
3. Run multiple instances of server.ts behind a load balancer. Because step 4 in the design notes still applies — the MCP protocol session (the Map in server.ts) is per-process — route by Mcp-Session-Id with sticky sessions, OR terminate the client connection per-request (stateless mode) if your client library supports it. The application conversation state (step 1–2) has no such constraint; it's already externalized and safe to hit from any instance.
4. Add a queue in front for burst absorption once traffic exceeds what autoscaling can react to in time (see architecture diagram earlier in the conversation).