API Gateway Pattern: Single Entry Point for Microservices

The problem it solves

Without a gateway, every microservice has to implement auth, rate limiting, TLS, CORS, logging, tracing, request validation — the cross-cutting concerns. With 50 services, that's 50 different implementations drifting apart, security gaps everywhere, every team reinventing the wheel.

The API Gateway centralizes those concerns into one tier. Clients talk to one URL; the gateway handles auth, rate-limiting, routing, observability, then forwards to the right backend service.

What belongs in the gateway

Always: TLS termination, auth (JWT/OAuth validation), rate limiting, logging, metrics, distributed tracing header propagation, routing, basic input validation, CORS, security headers.

Sometimes: response caching, request/response transformation (REST ↔ gRPC), aggregation for BFF, circuit breaking, retries, canary routing, A/B test injection.

Never: business logic. The moment the gateway knows that 'an order with status SHIPPED can't be cancelled,' it's become a microservice itself — a coupling disaster. Validate JSON shape sure; validate 'productId 42 in stock' is the product service's job.

BFF — Backend-for-Frontend

Mobile apps need different data shapes than web. Forcing both into one API leads to over-fetching or under-fetching. Solution: one gateway per client type — mobile BFF, web BFF, partner API gateway.

Each BFF can:

• Aggregate multiple service calls into one response (product page = product + reviews + recommendations)
• Serve different formats (Protobuf for mobile size, JSON for web)
• Iterate independently — owned by the client team

GraphQL gateways are a fancy BFF flavor — client picks fields, gateway federates to services.

Edge gateway vs service mesh — different layers

Edge gateway: north-south traffic. Sits between clients and services. Auth, rate-limit per API key, public TLS. Kong, AWS API Gateway, Spring Cloud Gateway.

Service mesh: east-west traffic. Sits between services as sidecars. mTLS, retries, circuit breaking, traffic shifting. Istio, Linkerd.

Mature microservices have both. Lighter setups skip the mesh and let the gateway handle some cross-service concerns.

Operational realities

Gateway = critical path. If it goes down, everything goes down.

• HA: multiple instances, multi-AZ, graceful drain on deploys
• Latency: adds 1-5ms baseline; avoid sync remote calls in the request path; cache auth/rate-limit aggressively
• Config drift: hundreds of routes; declarative config (Kong DB-less, YAML), CI-controlled deploys
• Security: don't trust client headers — strip, then add gateway-set ones (X-Auth-User)
• Versioning: route by header or URL prefix (/v1, /v2); sunset headers for deprecation

When NOT to use a gateway

• Tiny systems: an NGINX + a lambda for auth is enough
• Pure internal systems with no external traffic: service mesh might suffice
• Strict <5ms latency budget: the hop may be too expensive
• Gateway logic creep: thousands of lines of conditional transforms = it's becoming a service. Split into a BFF or push back into the actual service.

Recommendation

Use an API Gateway for any system with multiple microservices and external clients. Centralize TLS, auth, rate limiting, observability — keep business logic out. For multiple client types, layer BFFs on top per client. Pair with a service mesh for east-west zero-trust. Treat the gateway as critical infrastructure: HA across AZs, low baseline latency, declarative config under CI control. Common picks: Kong, Spring Cloud Gateway, AWS API Gateway for managed; Envoy or Istio Ingress for self-hosted.