API Gateways & the Edge

You shipped three services. Now what's the URL?

You split your app into a few services, one for auth, one for orders, one for payments. Each runs somewhere, each has its own host and port. Now your mobile app needs to call them. Do you hand the client three different URLs? Who checks the token? Who stops a bad actor from hammering the login endpoint 10,000 times a second? Who adds CORS headers, strips the internal X-Debug header, and caches that one expensive response?

The honest answer for most teams is: an API gateway. It's the single front door that every request passes through before it reaches a backend service, and once you have one, a whole category of cross-cutting problems stops living in your application code.

One sentence, then a picture in your head

An API gateway is a reverse proxy that sits in front of your services and handles routing, authentication, rate limiting, transforms, and caching, so each service doesn't have to.

If that still feels abstract, borrow the hotel. Guests don't wander into the kitchen, the laundry, or the manager's office directly. They walk up to the front desk, and the concierge handles everything from there.

Where it sits

The gateway lives between the public internet and your private services. In front of it, at the very edge, sits a WAF and usually a CDN. Behind it, your services stay on a private network and never take traffic directly from clients.

1. 1

   Request hits the edge

   The client calls one hostname over HTTPS. The WAF inspects it first and drops anything matching known attack patterns.

2. 2

   Gateway authenticates

   Clean traffic reaches the gateway, which validates the token or API key. No token, no entry, the backend never sees the request.

3. 3

   Rate limit is checked

   The gateway counts requests for this client in the current window. Over the limit returns 429 immediately, sparing the backend.

4. 4

   Route and (maybe) cache

   The path is matched to a backend route. If a fresh cached response exists, it's returned without touching the service at all.

5. 5

   Transform and forward

   The gateway rewrites headers/paths as needed, forwards to the private service, then shapes the response on the way back out.

What the gateway is actually responsible for

The pitch for a gateway is consolidation: every concern below would otherwise be re-implemented (slightly differently, slightly buggily) in each service. Centralize them once.

What a route + rate-limit policy looks like

Most gateways are configured declaratively, you describe routes and policies, the gateway enforces them. Here's a vendor-neutral shape: a route for the orders service with JWT auth, a per-client rate limit, and a short response cache.

routes:
  - name: orders
    match:
      path: /orders/*
      methods: [GET, POST]
    upstream:
      service: orders-service.internal
      port: 8080
    policies:
      # 1. Require a valid JWT before forwarding
      auth:
        type: jwt
        issuer: https://auth.example.com
        audience: orders-api
        forward_claims: [sub, scope]

      # 2. 100 requests per minute, per client key
      rate_limit:
        requests: 100
        per: minute
        key: ${request.header.X-Client-Id}
        on_exceeded:
          status: 429
          body: "Rate limit exceeded. Retry shortly."

      # 3. Cache successful GETs for 30s
      cache:
        methods: [GET]
        ttl: 30s
        vary: [Authorization]

      # 4. Shape the request/response
      transform:
        request:
          remove_headers: [X-Debug, X-Internal-Trace]
        response:
          add_headers:
            Access-Control-Allow-Origin: https://app.example.com

Read it top to bottom and you've read the request lifecycle: authenticate, rate limit, serve from cache if possible, transform, forward. No business logic anywhere in here, that's the point.

Managed options you'll actually meet

You rarely build a gateway from scratch. Each major cloud has a managed one, and Apigee is the heavyweight cross-cloud option for serious API programs. They differ in polish and price, not in the fundamentals above.

• AWS API Gateway, deep integration with Lambda and IAM; REST and HTTP APIs; pay-per-request. The default if you're already on AWS.
• Azure API Management (APIM), strong policy engine (XML-based transforms), a built-in developer portal, and tiered pricing. Common in enterprise Azure shops.
• Google Apigee, full API *management* platform: monetization, analytics, lifecycle, and a polished portal. Heavier and pricier; chosen when APIs are the product.
• Self-managed (Kong, NGINX, Envoy), open-source data planes you run yourself. Maximum control, you own the upgrades, scaling, and on-call.

The WAF and the edge

A Web Application Firewall sits one hop in front of the gateway, at the edge of your network. Where the gateway asks "who are you and where are you going?", the WAF asks "does this request look malicious?" It inspects requests against rules, known SQL injection and XSS patterns, suspicious user agents, traffic floods, requests from flagged IP ranges, and drops the bad ones before they cost you anything downstream.

The edge is also where your CDN lives, terminating TLS close to users and serving static content from points of presence worldwide. WAF rules typically run right there, so an attack is filtered near its origin rather than after crossing the globe to your gateway. For the CDN side of this story, see CDN & Edge Compute.

Common mistakes that cost hours

1. Business logic in the gateway. It's tempting to add "just one" pricing rule or order check in a transform. Now your business logic is split across two systems with different deploy cycles. Keep the gateway dumb about your domain.
2. No rate limiting. Without it, one buggy client or one attacker can take down every service behind the gateway at once. Set sane per-client limits from day one, even generous ones.
3. Treating the gateway as a single point of failure. Everything flows through it, so if it's one box, it's *the* outage. Run it across multiple instances and availability zones, and health-check it like the critical infrastructure it is.
4. Skipping the WAF because "the gateway has auth." Auth checks identity; it does not catch injection or floods. They solve different problems.
5. Caching authenticated responses without a `vary` key. Cache a logged-in user's data without varying on their token and you'll serve their data to the next person. Always vary on the auth header.

Takeaways

Where to go next

The gateway handles the front door, but the contracts your services expose through it matter just as much. Pair this with the design and edge sides of the picture, then put it into practice on the path.

• Read Secure API Design for the contract and auth patterns the gateway enforces.
• Read CDN & Edge Compute to go deeper on what else lives at the edge.
• Practice routing and proxy concepts in the networking lab.
• Follow the full track on the Cloud Engineer path.