Clean • Professional
In a microservices architecture, clients should not communicate directly with multiple services.
An API Gateway acts as a single entry point that receives all client requests and routes them to the appropriate backend microservices.
It works as a traffic controller, security layer, and cross-cutting concern handler, keeping microservices clean and loosely coupled.
An API Gateway is a reverse proxy that sits between clients and backend microservices. It acts as a single entry point for all incoming requests and manages how those requests are handled inside the system.
Instead of clients communicating with multiple microservices directly, they send requests to the API Gateway, which then forwards them to the appropriate service.
An API Gateway typically handles:
An API Gateway simplifies, secures, and manages communication between clients and microservices through a single, centralized entry point.
In a microservices architecture, applications consist of many small, independent services. Without proper coordination, client communication quickly becomes complex and hard to manage. This is where an API Gateway becomes essential.
When there is no API Gateway, clients must communicate with each microservice directly.
Direct Communication Example:
Client → Order Service
Client → Payment Service
Client → Inventory Service
This approach increases complexity on the client side and makes the system harder to maintain as it grows.
An API Gateway introduces a single entry point between clients and microservices.
Benefits:
Gateway-Based Communication:
Client → API Gateway → Microservices
Clients remain simple, while microservices focus purely on business logic.
An API Gateway acts as a single entry point for all client requests in a microservices system. It centralizes common responsibilities, keeping services simple and independent.
1. Request Routing
Directs requests to the correct microservice based on path or method.
Example routing rules:
/api/orders → Order Service
/api/payments → Payment Service
/api/users → User Service
2. Load Balancing
Distributes traffic across healthy service instances using service discovery.
Gateway → Load Balancer → Service Instance
3. Security
Handles authentication (JWT/OAuth2) and authorization centrally.
📌 Backend services trust the gateway and stay simple.
4. Cross-Cutting Concerns
Manages logging, rate limiting, caching, request transformation, and tracing.
5. API Versioning
Supports multiple API versions without breaking clients.
/v1/orders
/v2/orders
Spring Cloud Gateway is the official API Gateway for Spring Boot microservices.
Key Features
Why Use Spring Cloud Gateway?
It offers a lightweight, flexible, and production-ready solution for routing, security, and traffic control in microservices architectures.
A Route defines which service a request should go to.
A Route contains:
Predicates define conditions to match incoming requests.
| Predicate | Purpose |
|---|---|
| Path | Match URL path |
| Method | Match HTTP method |
| Header | Match request header |
| Query | Match query parameter |
| Host | Match domain |
Example:
predicates:
-Path=/orders/**
-Method=POST
➡ Route is selected only if all predicates match.
Filters allow you to modify requests or responses before or after routing.
Common Filter Use Cases
Client
↓
API Gateway
↓
[ Predicates → Filters ]
↓
Target Microservice
Dependency (Maven)
Add spring-cloud-starter-gateway to enable Spring Cloud Gateway in your project.
This provides routing, predicates, filters, and reactive support out of the box.
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
Gateway Application
The gateway is a regular Spring Boot application.
@SpringBootApplication bootstraps the gatewaySpringApplication.run() starts the gateway server@SpringBootApplication
publicclassApiGatewayApplication {
publicstaticvoidmain(String[] args) {
SpringApplication.run(ApiGatewayApplication.class, args);
}
}
application.yml
spring:
cloud:
gateway:
routes:
- id: order-service
uri: lb://ORDER-SERVICE
predicates:
- Path=/orders/**
filters:
- AddRequestHeader=X-Gateway, SpringCloud
lb:// enables Eureka + Spring Cloud LoadBalancer
Predicates define conditions for routing requests.
| Predicate | Example | Description |
|---|---|---|
| Path | /orders/** | Matches request URL paths |
| Method | GET, POST | Matches HTTP methods |
| Header | X-Request-Id | Matches specific HTTP headers |
| Query | ?version=1 | Matches query parameters |
| Host | api.company.com | Matches request host/domain |
Example Usage in application.yml:
predicates:
- Path=/orders/**
- Method=POST
Filters allow you to intercept and modify HTTP requests or responses as they pass through the API Gateway.
Example: Add a Header
filters:
- AddRequestHeader=X-Request-Source, API-Gateway
- Retry=3
@Component
public class LoggingFilter implements GlobalFilter {
@Override
public Mono<Void> filter(ServerWebExchange exchange,
GatewayFilterChain chain) {
System.out.println("Request Path: " +
exchange.getRequest().getPath());
return chain.filter(exchange);
}
}
Flow Diagram:
Client → API Gateway → Eureka → Service Instance
Example: Redis Rate Limiter
filters:
- name: RequestRateLimiter
args:
redis-rate-limiter.replenishRate: 10
redis-rate-limiter.burstCapacity: 20
Explanation:
replenishRate: Requests per secondburstCapacity: Maximum burst of requests| Feature | Direct Calls | API Gateway | Notes |
|---|---|---|---|
| Client Complexity | High | Low | Clients must know multiple service URLs in direct calls; API Gateway abstracts them |
| Security | Distributed | Centralized | Each service handles auth individually vs Gateway managing it centrally |
| Load Balancing | Client-managed | Gateway-managed | Clients choose instances vs Gateway automatically balances requests |
| Scalability | Hard | Easy | Direct calls scale poorly; Gateway allows consistent, scalable routing and policies |
| Feature | API Gateway | Service Discovery |
|---|---|---|
| Purpose | Entry point for clients | Internal service lookup |
| Routing | Handles routing, load balancing, and request filtering | Provides dynamic service addresses for clients to call |
| Security | Centralized authentication, authorization, rate limiting | Not responsible for security |
| Client vs Service | Client-facing | Service-facing |
| Use Case | Simplifies client interactions and centralizes cross-cutting concerns | Enables microservices to discover and communicate with each other dynamically |
👉 They complement each other, not replace each other.
Client
↓
API Gateway
├── /orders → Order Service
├── /payments → Payment Service
└── /inventory → Inventory Service
Gateway handles:
API Gateway is the nervous system of microservices architecture.
It enables:
👉 API Gateway + Eureka + LoadBalancer = Scalable Microservices Architecture