Engineering Deep Dive · Engineering · AI Infrastructure

LLM Gateway: Control plane between apps and model providers

Routing, tenancy, cost governance, and observability between applications and model providers.

Prototype

Challenge → Tradeoffs → Architecture → Implementation → Validation

IntrofinityView source

Direct provider coupling ages badly

Early AI features often hard-wire an SDK call to one model vendor. That works until a second team needs Anthropic, a third needs Azure OpenAI, finance asks for budgets, security asks for audit trails, and operations asks why one workspace burned the monthly quota overnight.

The gateway thesis is simple:

Applications should talk to a control plane. The control plane talks to providers.

That is more than URL rewriting. A gateway becomes policy, tenancy, routing, and observability infrastructure for every model call an organization makes.

Capabilities that define the product

The LLM Gateway work focused on enterprise control surfaces:

  • Multi-provider routing — unified interface across OpenAI, Anthropic, and Azure OpenAI with failover and load balancing
  • Tenant isolation and RBAC — workspaces, permissions, and quotas per team
  • Cost and usage governance — request tracking, budgets, analytics, and rate limits
  • Observability and auditability — logging, metrics, and trails for compliance
  • Interactive playground — prompt and model experimentation before production wiring
  • Enterprise authentication — Azure AD with JWT session handling

Design targets included sub-3s P95 responses, horizontal scaling for high concurrency, and multi-layer caching for cost and latency.

What real migrations taught

Hands-on gateway work exposed problems that demos skip: model-group configuration, unsupported parameters across providers, API compatibility gaps, key migration, and the quiet fact that “the same model name” is not the same contract everywhere.

Those issues prove the architectural point. A gateway that only proxies chat completions will still leave every application to rediscover provider differences. A useful gateway owns a model registry, provider abstraction, routing, fallback, authentication, policy, usage, cost, and tracing as first-class concerns.

Stack shape

The system shape used Next.js and React for admin and playground surfaces, NestJS with GraphQL for backend services, PostgreSQL as the system of record, Redis for cache and session state, Docker for deployment packaging, and Azure AD for identity. The public showcase documents architecture and UI structure; production business logic remains proprietary where required.

What this case study claims

Enterprises do not need another chat UI. They need a governed path from application intent to provider execution. The gateway is that path — the single pane of glass for routing, tenancy, cost, and audit across AI usage.

Showcase: github.com/syedsadiq27/llm-gateway-showcase

← All work