API gateway and service discovery
An API gateway such as Spring Cloud Gateway is the single entry point for clients. It handles routing, authentication (validating JWTs), rate limiting, CORS, request logging and sometimes response aggregation.
Service discovery matters because instances start, stop and move, so hard-coded URLs break.
- Client-side discovery: services register in Eureka (or Consul), and callers look them up and load-balance with Spring Cloud LoadBalancer.
- Platform discovery: on Kubernetes, a Service gives a stable DNS name such as
http://order-serviceand load-balances for you, so Eureka is usually unnecessary.
Centralized configuration comes from Spring Cloud Config or Kubernetes ConfigMaps.
Example
@Configuration
class GatewayRoutes {
@Bean
RouteLocator routes(RouteLocatorBuilder builder) {
return builder.routes()
.route("catalog", r -> r.path("/api/v1/courses/**", "/api/v1/lessons/**")
.uri("lb://catalog-service")) // resolved through discovery
.route("orders", r -> r.path("/api/v1/orders/**")
.filters(f -> f.addRequestHeader("X-Gateway", "javaatlas")
.retry(3))
.uri("lb://order-service"))
.build();
}
}Common mistake
Calling other services by the hard-coded IP or hostname of one instance. Use discovery names or Kubernetes Service DNS instead.
Under the hood
Keep the gateway thin: routing and cross-cutting concerns only, never business logic, or it becomes a new monolith. The Backend for Frontend pattern gives web and mobile clients separate gateways tuned to their needs. Rate limiting usually uses Redis-backed token buckets. Health endpoints (/actuator/health/liveness and /actuator/health/readiness) let Kubernetes send traffic only to ready instances.
Check yourself
On Kubernetes, what usually replaces Eureka?
How this connects
Know these first
Where this leads
You've reached the end of this thread. Try a learning path for what's next.
Part of Microservices and production.
Was this lesson helpful?
Finished reading? Mark it complete to track your progress.