API Gateway

Provide a single, managed entry point for all client requests that handles routing, authentication, rate limiting, protocol translation, and observability : decoupling clients from the internal service topology.

Clients coupling directly to individual services creates fragile integrations that require client changes for every service topology change, and forces each service to independently implement authentication, rate limiting, and observability.

Without an API gateway, each client must know the address of every service, authenticate independently, and handle rate limiting errors from multiple sources. Adding a new service or changing an existing one requires client changes. Observability requires per-service instrumentation.

An API gateway is a reverse proxy that sits at the edge of the system and centralises these cross-cutting concerns. Clients connect to a single endpoint. The gateway resolves routing (path /orders → order-service:8080, path /payments → payment-service:8081), verifies JWT tokens or API keys before forwarding requests, enforces rate limits (e.g., 1,000 req/min per API key from a Redis counter), translates protocols (REST client → gRPC backend), and emits standardised access logs and metrics for every request.

Rate limit state requires shared storage accessible to all gateway replicas; Redis is the standard choice (INCR + EXPIRE on a per-key counter). A per- replica in-memory counter allows clients to exceed the limit by a factor of (N replicas × limit) before being rejected: unacceptable for enforcement.

An API gateway is a potential single point of failure: all traffic flows through it. High-availability deployment (minimum 2 replicas, preferably 3, behind a load balancer) is mandatory. The gateway must be stateless so that any replica can handle any request; state (sessions, rate limit counters) must be externalised to Redis or a distributed store.

As traffic grows, the gateway can become a throughput bottleneck. Horizontal scaling is straightforward (stateless + externalised state), but each gateway replica adds a network hop. For latency-sensitive paths, direct service-to- service communication (service mesh) is preferred over gateway routing.