MCP Architecture Patterns: A Field Guide

MCP is not a single pattern. It is a family of patterns, each with different tradeoffs. This field guide maps the four production patterns we have shipped, when to use each, and where they break.

This is written for engineering teams evaluating MCP infrastructure. It is not a tutorial. It assumes you understand MCP basics and are deciding how to deploy.

Pattern 1: Single-Server Direct

Topology: One MCP server, multiple clients connect directly.

[Client A] [Client B] -- [MCP Server] -- [Tools/Resources]
[Client C] /

When to use:

• Small team (1-10 engineers)
• Single project or workspace
• No shared state requirements
• Fastest time-to-production

Tradeoffs:

• Pro: Simplest to deploy. One process, one config, one log stream.
• Pro: Lowest latency. No network hops between client and server.
• Con: Single point of failure. Server down = everyone down.
• Con: No horizontal scaling. All tool execution on one machine.
• Con: No multi-tenant isolation. All clients share the same context.

Where it breaks: At ~50 concurrent tool calls, the single server becomes a bottleneck. Tool execution latency degrades non-linearly because the event loop saturates.

Production notes: Run behind a load balancer with health checks. Use systemd or Docker with restart=always. Monitor tool execution time, not just server uptime. A server that is up but taking 30s per tool call is worse than a server that is down.

Pattern 2: Gateway-Router

Topology: Multiple MCP servers behind a gateway that routes requests.

                 [MCP Server A] -- [Tools: filesystem, search]
[Client] -- [Gateway] -- [MCP Server B] -- [Tools: code-exec, database]
                 [MCP Server C] -- [Tools: web-fetch, api-calls]

When to use:

• Medium team (10-50 engineers)
• Multiple projects needing different tool sets
• Need for tool-level isolation
• Need for independent scaling of different tool categories

Tradeoffs:

• Pro: Tool-level isolation. A crash in code-exec doesn't take down filesystem.
• Pro: Independent scaling. Scale up code-exec servers without scaling search.
• Pro: Team-level tool access control. Route based on auth/role.
• Con: One extra network hop (client > gateway > server). Adds 5-15ms latency.
• Con: Gateway is a new failure surface. Must be highly available.
• Con: More operational complexity. 3+ processes to monitor.

Where it breaks: The gateway becomes a bottleneck if it does too much (auth, routing, logging, rate-limiting). Keep the gateway thin. It should route, not process.

Production notes: Use a reverse proxy (nginx, caddy) as the gateway, not a custom service. Custom gateways accumulate logic and become unmaintainable. Route by URL path prefix, not by header inspection. Path routing is debuggable; header routing is not.

Pattern 3: Federated Shared-State

Topology: Multiple MCP servers sharing a common state store (PostgreSQL, Redis).

[Client] -- [MCP Server A] \  
                            [Shared State Store] -- [Tools]
[Client] -- [MCP Server B] /

When to use:

• Large team (50+ engineers)
• Multiple workspaces needing shared context
• Long-running agent sessions that survive server restarts
• Need for cross-workspace tool state (e.g., shared vector memory)

Tradeoffs:

• Pro: Server restart does not lose session state.
• Pro: Cross-workspace collaboration (agents can see each other's context).
• Pro: Horizontal scaling with state consistency.
• Con: State store is a new failure surface and a consistency challenge.
• Con: Latency increases (every tool call may need state read/write).
• Con: Operational complexity is highest of the four patterns.

Where it breaks: At scale, the state store becomes the bottleneck. PostgreSQL handles ~1000 concurrent tool calls with shared state; beyond that, you need sharding or a distributed cache. The consistency model matters: if you use eventual consistency, agents may see stale state; if you use strong consistency, latency increases.

Production notes: Use PostgreSQL with connection pooling (pgbouncer or Supavisor). Do not use Redis as the primary state store; use it as a cache layer in front of PostgreSQL. Implement idempotent tool execution so retries do not produce side effects.

Pattern 4: Edge-Deployed

Topology: MCP servers deployed to edge locations (Cloudflare Workers, Deno Deploy) with centralized coordination.

                    [Coordination Layer]
                    /        |          [Client] -- [Edge A]   [Edge B]    [Edge C]
              |            |           |
           [Tools]     [Tools]     [Tools]

When to use:

• Globally distributed team
• Latency-sensitive tool execution (< 100ms target)
• Tools that can run in edge runtime (no heavy compute, no persistent connections)
• Need for geographic data residency

Tradeoffs:

• Pro: Lowest latency for geographically distributed teams.
• Pro: Edge handles failures gracefully (if Edge A is down, route to Edge B).
• Pro: Data residency compliance (tools run in the user's region).
• Con: Edge runtime constraints (no long-running processes, limited compute).
• Con: Coordination layer is complex and must be highly available.
• Con: Tool execution is limited to what the edge runtime supports.

Where it breaks: Tools that need heavy compute (LLM inference, large data processing) cannot run on the edge. The coordination layer becomes a consistency challenge: if two edges execute conflicting tool calls simultaneously, who wins?

Production notes: Use Cloudflare Workers for the edge runtime. Use Durable Objects for coordination (they provide strong consistency for single-key operations). Do not try to build your own coordination layer; it is harder than it looks.

Decision Framework

The Anti-Pattern: Monolith MCP

The most common mistake is building a single MCP server that does everything: filesystem, search, code execution, web fetching, database access, and custom domain tools. This is the monolith anti-pattern. It combines the limitations of Single-Server Direct (single point of failure, no scaling) with the complexity of Gateway-Router (too many tools in one process). It is the default architecture because it is the easiest to start with, and it is the hardest to migrate away from.

If you are starting: use Single-Server Direct with a clear plan to split into Gateway-Router when you hit the scaling wall. Do not start with a monolith.

If you are already in a monolith: split by tool category first (filesystem vs. compute vs. network), then by team access pattern. Do not try to split by feature; split by operational boundary.

What This Changes

For engineering teams: the question shifts from "should we use MCP" to "which MCP pattern matches our scale and operational capacity." The first question is binary. The second is a design decision with tradeoffs.

For the field: the question shifts from "is MCP production-ready" to "which MCP patterns are production-ready at which scale." The first question is generic. The second is specific and useful.

MCP is not a product. It is a protocol. The patterns above are how you deploy the protocol. The pattern you choose determines your operational burden, your latency profile, and your failure modes. Choose based on your constraints, not based on what is trendy.

---

For a technical audit of your MCP infrastructure, see the MCP Audit service. For production deployment, see Standard MCP Deployment.