What is an API Gateway, and what does Spring Cloud Gateway provide?

In a microservices architecture with many independently deployed services, having every client (a mobile app, a web frontend, a third-party integration) talk directly to each individual backend service creates real problems: clients need to know every service's address, cross-cutting concerns (authentication, rate limiting, logging, CORS) get duplicated across every service, and there's no single place to apply a system-wide policy change.

An API Gateway sits in front of the whole collection of services as a single, unified entry point: clients talk only to the gateway, which routes each request to the appropriate backend service and centralizes those cross-cutting concerns in one place instead of duplicating them everywhere.

Spring Cloud Gateway is Spring's implementation of this pattern, built on the reactive, non-blocking Spring WebFlux stack (chosen specifically because a gateway needs to efficiently handle a large volume of concurrent, often I/O-bound "just route this elsewhere" requests, which suits a non-blocking model well).

Core concepts:

• Routes — map an incoming request (matched by path, header, or other predicates) to a destination:

spring:
  cloud:
    gateway:
      routes:
        - id: order-service-route
          uri: lb://order-service        # "lb://" — load-balanced via service discovery
          predicates:
            - Path=/api/orders/**
          filters:
            - StripPrefix=1

• Predicates — conditions that determine whether a route matches a given request (path, header, method, query parameter, time-based, etc.).
• Filters — modify the request before it's forwarded, or the response before it's returned to the client — used for cross-cutting concerns applied centrally rather than per-service: adding/removing headers, rate limiting (RequestRateLimiter), authentication checks, request/response logging, and integrating a circuit breaker filter around a downstream call.

Why centralize this at the gateway rather than in each service:

• One place to change a cross-cutting policy — e.g., rolling out a new rate-limiting rule or authentication requirement across the whole API surface doesn't require touching every individual backend service.
• Simplifies clients — a single, stable entry point and URL structure, regardless of how backend services are actually organized, scaled, or renamed internally.
• Consistent enforcement — a security or rate-limiting rule enforced at the gateway can't be accidentally skipped by one service that forgot to implement it locally.

Trade-off: the gateway becomes a critical, shared piece of infrastructure — it needs to be highly available and carefully monitored, since every request now passes through it, making it both a natural place to centralize concerns and a potential single point of failure if not deployed and scaled appropriately.