API Gateway Architecture
An API gateway is the single entry point for external clients into a backend. It terminates the client connection and handles cross-cutting concerns — auth, rate limiting, routing, aggregation, TLS — in one place, so individual services do not each re-implement them. It owns north-south traffic (client ↔ system).
Without a gateway, every client must know the topology of internal services and each service must re-solve auth, throttling, and CORS. The gateway centralizes that: clients hit one endpoint, and the gateway routes to the right upstream while enforcing policy at the edge. It is the natural place to shed bad traffic before it reaches application servers. Source: compiled from API-gateway pattern literature
Responsibilities
- Routing / dispatch — map request path/host/headers to an upstream service (load-balancing across instances).
- Authn / authz — validate tokens/API keys once at the edge; pass a verified identity downstream so services trust the header.
- Rate limiting & quotas — enforce per-key limits here, earliest in the path (Rate Limiting Architecture).
- TLS termination — decrypt once at the edge.
- Aggregation / composition — fan one client request out to several services and merge responses (reduces client round trips).
- Transformation — protocol/version translation, request/response shaping.
- Resilience & caching — timeouts, retries, circuit breaking, and response caching at the edge.
Backend-for-Frontend (BFF)
When a web app and a mobile app need very different response shapes, one generic gateway forces awkward compromises. The BFF pattern gives each client type its own gateway, tailored to that client's needs, so each frontend gets an API shaped for it without bloating a shared one.
Gateway vs mesh
| | API gateway | Service mesh | |--|-------------|--------------| | Traffic | North-south (external→system) | East-west (service↔service) | | Concern | Client-facing policy, aggregation | Inter-service reliability, mTLS | | Placement | Edge | Sidecar per service |
They layer together: gateway at the edge, mesh inside.
Design implications
- Avoid the god-gateway. Pushing business logic into the gateway recreates a monolith and a deploy bottleneck; keep it to cross-cutting concerns.
- It is a critical SPOF — must be HA and horizontally scaled, fronted by a load balancer.
- Latency budget. Every request pays the gateway hop; keep its work cheap (the reject-early principle).
Kevin's Dedalus API Backend sits behind this shape: auth (DAuth), per-key throttling, and routing to agent/workspace services concentrate at the edge, with tenant identity resolved once and trusted downstream.
Architecture Position
| Axis | Value |
|---|---|
| Family | Distributed systems primitives |
| Boundary owned | External entry point, request routing, auth, rate limits, BFF, and gateway/mesh split. |
| Read with | Load Balancing Architecture, Rate Limiting Architecture, Service Mesh and Service Discovery Architecture |
| Use this page when | designing backend entry points |
Timeline
-
2026-07-01 | Architecture category refresh added this page to the Distributed systems primitives family, linked it to Architecture System Map, and kept it standalone because it owns this boundary: External entry point, request routing, auth, rate limits, BFF, and gateway/mesh split. Source: User request, 2026-07-01
-
2026-06-02 | Page created. Captured the single-entry-point rationale, the responsibility list (routing/auth/limits/TLS/aggregation/transform/resilience), the BFF variant, the north-south gateway vs east-west mesh distinction, and the god-gateway/SPOF/latency implications. Source: compiled from API-gateway / BFF pattern literature