API Gateway

A load balancer spreads traffic across instances, a reverse proxy fronts and shields backends with TLS and caching, and an API gateway adds API-specific auth, rate limiting, and aggregation -- they stack as complementary layers, not competing choices.

A forward proxy fronts clients and hides them from servers for egress control and anonymity, a reverse proxy fronts servers and hides them from clients for TLS, routing, and load balancing -- and Nginx or an API gateway in front of your services is a reverse proxy.

The API Gateway is the single front door that routes, secures, limits, aggregates, caches, and protects, so clients talk to one address and services stop repeating cross-cutting work.

The API Gateway pattern puts one thin edge service in front of all your services to own every cross-cutting concern, and nothing that is business logic.

Cache safe, shared, slowly changing reads at the gateway with a sensible TTL, and never cache per-user or sensitive data without strict per-identity keys and short expiry.

The gateway mints a trace ID and propagates it in standard headers; every service adds timed child spans; and a backend like Zipkin stitches them into one end-to-end timeline.

Zero trust means never trust and always verify every request, so the gateway enforces mutual TLS, short-lived JWT identity, dynamic authorization, and anomaly detection on every call.

Make every request single-use and fresh: a signed unique nonce plus a timestamp, reject stale timestamps outside a short window, and reject any nonce already seen in Redis with a TTL equal to the window.

Identify the tenant on every request, stamp and propagate a verified tenant context, and enforce per-tenant routing, limits, quotas, and data isolation so tenants share the platform but never each other's data or capacity.

Make every request cheap by reusing upstream connections, rate limiting locally with periodic Redis sync, batching logs asynchronously, and coalescing identical in-flight requests into one downstream call.

A RouteLocator is the gateway's route table, and backing it with a refreshable RouteDefinitionRepository lets you add, change, or shift routes at runtime without a redeploy.

Propagate identity from the gateway downstream by forwarding the bearer token for re-validation, or injecting verified claims as trusted headers, or exchanging the user token for a narrowly-scoped internal token, all over mutual TLS.

Microservices are independently deployable services, each owning its database, connected by an API Gateway, protected by circuit breakers, coordinated by Sagas, and observed through distributed tracing.

Blue-green runs old and new side by side and uses gateway weighted routing to shift traffic gradually from blue to green, with instant rollback by shifting the weights back.

Everything flows through the gateway, so per-request work is multiplied by all traffic; the rule is to do the least possible work per request, cache aggressively, and never block on synchronous I/O.

Take token verification off the hot path by verifying locally with cached keys, using a dedicated auth tier for pre-verified context tokens, or caching introspection results, and prefer ECDSA for faster verification throughput.