Skip to content

API Gateway Template — Architecture

Edge responsibilities

Concern Typical implementation
Routing Reverse proxy / route table to downstream clusters; path-based or host-based routes
Authentication at perimeter Validate JWTs, API keys, or forward to trusted IdP; optional claim transformation
Authorization Scope checks where policy belongs at edge; fine-grained domain authorization often remains downstream
Rate limiting / throttling Protect backends from abuse; per-client or per-route budgets
Cross-cutting HTTP Compression, CORS, correlation IDs, tracing headers
Optional BFF Aggregate or adapt responses for a specific client surface

Dependency injection (web stack)

Uses the same three-layer registration as other ConnectSoft web hosts:

  1. ApplicationModelRegistrationBase — shared application wiring from packages
  2. MicroserviceRegistrationBase — kernel services from base-template/
  3. ApiGatewayMicroserviceRegistration (template-specific) — routes, gateway options, gateway middleware

This keeps kernel concerns (health baseline, common logging) consistent while allowing gateway-only extension points.

Multi-tenancy

Gateways often infer tenant from:

  • Host name (e.g. {tenant}.api.example.com)
  • Path prefix (/t/{tenant}/...)
  • Headers (X-Tenant-Id, custom)

Downstream services must receive consistent tenant context (headers, JWT claims, or both). Align with platform multitenancy and configuration alignment.

Failure domains

  • Gateway failure impacts all routed traffic—prioritize health probes, rolling deploys, and circuit-breaking downstream calls.
  • Single point of policy: document which auth and rate-limit rules are only at the gateway vs duplicated in services.