API Gateway with Spring Cloud Gateway

An API gateway solves the N-endpoint problem — without it, every client needs to know the address of every microservice, handle auth tokens per service, and update when services scale or move. The gateway is a single front door that handles routing, JWT validation, rate limiting, and TLS termination centrally for all downstream services.

Spring Cloud Gateway internals:

• Built on Project Reactor and Netty — fully non-blocking, one thread handles thousands of concurrent connections; this is the key difference from old Netflix Zuul's thread-per-request model that exhausted pools under load
• Routes are defined with predicates (path, method, headers) and filters (strip prefix, add headers, rate limit); the lb:// URI scheme integrates with service discovery so routes use logical service names instead of hardcoded IPs
• A GlobalFilter applies to every request — implement JWT validation here so downstream services never see unauthenticated traffic

The pitfalls:

• The gateway is a single point of failure — if it crashes, every service is unreachable; run at least three instances behind a load balancer with readiness probes
• Keep the gateway thin — authentication and rate limiting belong here, but business orchestration does not; a gateway that calls five services and merges their responses is a monolith at the edge
• Circuit breaker per route prevents one slow backend from blocking the event loop and starving healthy routes

I recommend Spring Cloud Gateway over Zuul for any new setup, and keeping the gateway strictly thin — cross-cutting concerns only, no business logic.