API Gateway

Implement an API Gateway with Spring Cloud Gateway — the single entry point for all microservices that handles routing, authentication, rate limiting, and cross-cutting concerns.

Last reviewed: January 2025

·Spring Boot 3.xSpring Cloud 2023.xSpring Cloud Gateway
✅
Quick Understanding: An API Gateway is the single entry point for all client requests. It routes requests to the right microservice, validates JWTs, applies rate limiting, handles CORS, and aggregates responses. Spring Cloud Gateway is the reactive, non-blocking replacement for Netflix Zuul. Define routes in application.yml or Java DSL.

🔍 What Is It?

Spring Cloud Gateway is a reactive API Gateway built on Spring WebFlux.

What an API Gateway does:

  • →Routing — forward /api/orders/** to order-service
  • →Authentication — validate JWT before forwarding
  • →Rate limiting — limit requests per client
  • →Load balancing — distribute across service instances
  • →SSL termination — HTTPS at the gateway, HTTP internally
  • →Request/Response transformation — add/remove headers
  • →Circuit breaking — fallback if service is down
  • →Logging & tracing — add correlation IDs

Key concepts:

  • →Route — a rule: if predicate matches, apply filters and forward
  • →Predicate — matches conditions (path, method, header, host)
  • →Filter — modifies request/response (add header, rate limit, auth)

🎯 Why Do We Need It?

Without a gateway, clients must know about every microservice and call them directly. Cross-cutting concerns (auth, rate limiting, logging) must be duplicated in every service. The gateway centralizes these concerns and provides a unified API surface.

🏗️ What Happens in Real Projects?

Enterprise gateway setup:

  • →Single public URL: api.company.com
  • →Routes to: order-service, product-service, user-service, payment-service
  • →JWT validation at gateway — downstream services trust the gateway
  • →Rate limiting per API key
  • →Circuit breaker to fallback page if service is down

⚙️ How It Works

Spring Cloud Gateway is built on Netty and WebFlux — fully reactive, non-blocking. Each request is matched against routes in order. The first matching route's filters are applied, then the request is forwarded. Filters can be global (apply to all routes) or per-route.

💻 Example

API Gateway Configuration — Route configuration, JWT filter, and rate limiting.

yaml
spring:
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: lb://order-service  # lb:// = load balanced via Eureka
          predicates:
            - Path=/api/v1/orders/**
          filters:
            - StripPrefix=0
            - name: RequestRateLimiter
              args:
                redis-rate-limiter.replenishRate: 100
                redis-rate-limiter.burstCapacity: 200
                key-resolver: "#{@userKeyResolver}"

        - id: product-service
          uri: lb://product-service
          predicates:
            - Path=/api/v1/products/**
          filters:
            - name: CircuitBreaker
              args:
                name: product-service
                fallbackUri: forward:/fallback/products

        - id: user-service
          uri: lb://user-service
          predicates:
            - Path=/api/v1/users/**

      # Global filters applied to all routes
      default-filters:
        - AddRequestHeader=X-Gateway-Source, api-gateway
        - name: Retry
          args:
            retries: 3
            statuses: BAD_GATEWAY,SERVICE_UNAVAILABLE

🤔 Common Confusions

❓ Spring Cloud Gateway vs Netflix Zuul — which to use?

Spring Cloud Gateway for new projects. Zuul 1.x is blocking (servlet-based) and Netflix stopped active development. Spring Cloud Gateway is reactive (Netty-based), non-blocking, and actively maintained. Zuul 2.x is also non-blocking but has much less Spring integration. Spring Cloud Gateway is the standard choice.

❓ Should I validate JWT in the gateway or in each service?

Validate in the gateway, trust in the services. The gateway validates the JWT signature and expiry, then adds user info as headers (X-User-Id, X-Username, X-Roles). Downstream services trust these headers (they come from the internal network, not the client). This avoids each service needing the JWT secret and reduces latency.

🚨 Common Production Issues

Gateway becoming a single point of failure — deploy multiple gateway instances behind a load balancer

Rate limiting state not shared — use Redis-backed rate limiter for distributed rate limiting

Large request bodies causing memory issues in gateway — configure max body size

✅ Best Practices

Deploy multiple gateway instances — never a single point of failure

Use Redis for distributed rate limiting state

Log all requests at the gateway with correlation IDs

Validate JWT at the gateway, pass user info as trusted headers to services

Use circuit breakers with fallback responses for all routes

🏛️ Architect's Note

Senior Architect's Perspective

The API Gateway is the boundary between the public internet and your internal services. Everything that crosses this boundary should be authenticated, rate limited, and logged. Keep the gateway thin — it should route and apply cross-cutting concerns, not contain business logic. Business logic in the gateway becomes a bottleneck and couples all services to it.

💬 Frequently Asked Questions

How do I handle CORS in a microservices architecture?

Configure CORS at the API Gateway only. Downstream services don't need CORS config because requests come from the gateway (same origin). Add a CORS GlobalFilter in the gateway that sets Access-Control-Allow-Origin headers. Never configure CORS in both the gateway and individual services — it causes conflicts.

🎯 Key Takeaways

1API Gateway is the single entry point for all client requests
2Spring Cloud Gateway is reactive (Netty-based), not blocking like Zuul
3Routes defined by predicates (path, method) and processed by filters
4Validate JWT at the gateway; pass user info as trusted headers to services
5Use Redis-backed rate limiting for distributed rate limiting
6Deploy multiple gateway instances — never a single point of failure

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Spring Boot references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages

SplashRide Spring Boot learning path

Browse the full Spring Boot topic collection and learning order on SplashRide.

Spring Boot Interview Prep

Practice Spring Boot interview questions and scenario-based answers.

Backend Engineer Career Path

A structured journey through Core Java, Spring Boot, production backend engineering, and interview preparation.

Full Stack Java Developer Career Path

A guided route through frontend foundations, Java backend engineering, delivery workflows, and interview readiness.

Service Discovery

Implement service discovery with Spring Cloud Eureka — enabling microservices to find each other dynamically without hardcoded URLs.

Config Server

Centralize configuration for all microservices with Spring Cloud Config Server — manage environment-specific properties from a Git repository without redeployment.