If you have 20 microservices, your frontend mobile app should not communicate with them directly. If it did, the app would need to know the IP address of all 20 services, and every single service would have to independently implement JWT validation, rate limiting, and CORS. An API Gateway acts as the single entry point (the Front Door) for all external traffic, centralizing these cross-cutting concerns.

Module 1: The Role of the API Gateway

Industry-standard Gateways (like Kong, Envoy, or Nginx) are deployed at the edge of your network.

Core Gateway Responsibilities

  • Routing: Directing api.company.com/users to the User Service, and /billing to the Billing Service.
  • Authentication: Validating the JWT signature before the request ever reaches the internal microservice.
  • Rate Limiting: Blocking IPs that make more than 100 requests per minute to prevent DDoS attacks.
  • SSL Termination: Decrypting the HTTPS traffic at the gateway, and forwarding raw HTTP internally to save CPU cycles on the microservices.

Module 2: Configuring a Gateway (Kong/Nginx)

Gateways are configured declaratively. Here is an example of setting up routing and rate limiting.

kong.yamlyaml
_format_version: "2.1"
services:
  - name: user-service
    url: http://internal-user-service:3000
    routes:
      - name: user-routes
        paths:
          - /api/v1/users
    plugins:
      # Centralized Rate Limiting
      - name: rate-limiting
        config:
          minute: 60
          policy: local
      # Centralized JWT Validation
      - name: jwt
        config:
          claims_to_verify:
            - exp
            - iat

Module 3: Backend for Frontend (BFF Pattern)

A mobile app has different data needs than a complex desktop web dashboard. Instead of forcing one generic API Gateway to serve both, we use the BFF pattern. You deploy two smaller Gateways: one optimized for Mobile (stripping out heavy data payloads) and one for Web. The BFF aggregates data from multiple microservices so the client only has to make one HTTP call.

Module 4: Evolution to the Service Mesh

An API Gateway manages North-South traffic (from the outside internet into your cluster). But what manages East-West traffic (Service A talking to Service B inside the cluster)?

If Service A calls Service B, how do we encrypt that internal traffic? How do we implement circuit breakers between them? We use a Service Mesh (like Istio or Linkerd).

The Sidecar Proxy Patternmarkdown
Instead of putting logic in the application code, a Service Mesh automatically injects a tiny Proxy Container (Envoy) next to every single Pod in your Kubernetes cluster. 

[ Pod A: Node.js App <-> Envoy Proxy ]
               |
          (mTLS Encrypted Network)
               |
[ Pod B: Python App <-> Envoy Proxy ]