API Gateways for Microservices

By Kokil Thapa | Last reviewed: September 2026

Your mobile app should not call twelve internal URLs to place one order. API gateways for microservices sit at the edge and give clients a single front door. They route traffic, enforce auth, apply rate limits, and hide service topology. I've used this pattern on production Laravel and Symfony systems where booking, payments, and document APIs grew faster than the team could manage direct client-to-service wiring.

Without a gateway, every new microservice becomes a public integration point. That spreads security rules, CORS config, and versioning logic across codebases. A gateway concentrates cross-cutting concerns where they belong—before requests hit your domain services. This guide covers architecture, gateway selection, real configuration patterns, and the production mistakes I see most often.

What is an API gateway and why do microservices need one?

An API gateway is a reverse proxy with policy. It terminates HTTPS, validates tokens, maps public URLs to internal routes, and returns consistent error shapes. In a monolith, your framework middleware does this work. In microservices, someone must do it at the boundary.

Think of the gateway as your application's front desk. Clients check in once. The gateway knows which internal team handles the request. Services stay private on internal networks or VPC subnets. Only the gateway needs a public IP or load balancer listener.

Gateways solve problems that multiply with service count. Without one, you duplicate JWT validation in five Laravel apps. You expose internal hostnames in mobile builds. You cannot throttle abusive clients globally because each service tracks limits independently.

Core responsibilities at the edge

• Routing: Map /v1/orders/{id} to the order service upstream.
• Authentication: Validate OAuth2, JWT, or API keys before forwarding.
• Rate limiting: Protect backends from traffic spikes and abuse.
• TLS termination: Handle certificates once at the edge.
• Request/response transformation: Strip internal headers, normalise error JSON.
• Observability: Central access logs, trace IDs, and metrics export.

On legal-tech portals I've shipped, document upload and payment callbacks both need stable public URLs. The gateway keeps those endpoints constant even when internal services move or scale. That stability matters for third-party webhooks and mobile app store review cycles.

How does an API gateway handle traffic in a microservices architecture?

Every request follows a predictable pipeline. The gateway receives HTTP traffic, runs a chain of plugins or middleware, selects an upstream, and proxies the call. Responses flow back through the same path. Distributed tracing headers attach at step one so downstream services join one trace.

Routing patterns that scale

Path-based routing is the default. /api/v1/users/* goes to the user service. /api/v1/payments/* goes to payments. Host-based routing helps when partners need branded subdomains. Header-based routing supports canary releases—send 5% of traffic with header X-Canary: true to the new version.

Aggregation is where gateways earn their keep. A mobile home screen might need user profile, recent orders, and notifications. Instead of three round trips from the phone, a gateway route calls three upstreams and merges JSON. BFF (Backend for Frontend) layers often live behind or inside the gateway tier.

Example Kong route definition

Kong remains a common self-hosted choice. This declarative snippet routes order traffic and applies a rate limit plugin. For deeper Kong setup, see the Kong API gateway guide.

# kong.yml (declarative config excerpt)
_format_version: "3.0"

services:
  - name: order-service
    url: http://order-svc.internal:8080
    routes:
      - name: orders-v1
        paths:
          - /api/v1/orders
        strip_path: false
    plugins:
      - name: rate-limiting
        config:
          minute: 120
          policy: redis
          redis_host: redis.internal
      - name: jwt
        config:
          claims_to_verify:
            - exp

Laravel Sanctum or Passport still issue tokens. The gateway validates them at the edge. Services can trust an internal header like X-User-Id set only by the gateway. Never trust that header on a publicly reachable service. For token patterns in Laravel, read Laravel API best practices and Passport vs Sanctum comparison.

Observability hooks

Generate or forward a X-Request-Id at the gateway. Pass it to every upstream. Correlate gateway access logs with application logs and microservices observability stacks. Prometheus metrics at the gateway—request rate, 4xx/5xx ratio, upstream latency—catch problems before individual services alert. Pair this with API monitoring using Prometheus and Grafana for dashboards that ops teams actually watch.

Which API gateway should you choose for your stack?

No single gateway wins every scenario. Managed cloud gateways reduce ops burden. Self-hosted options give control and avoid per-request billing. Lightweight reverse proxies work when you need routing only—not a full plugin ecosystem.

For a full three-way breakdown, read Kong vs Traefik vs AWS API Gateway. Traefik fits container-heavy deployments—see Traefik as an API gateway. KrakenD suits aggregation-heavy mobile backends—see KrakenD stateless gateway patterns.

Decision criteria for small teams

1. Team size: Under five engineers? Prefer managed AWS API Gateway or a single Traefik instance over running Kong with HA Postgres.
2. Hosting: Bare Ubuntu VPS with Apache? Nginx or OpenResty at the edge matches what you already operate. See Linux system administration patterns for PHP-FPM stacks.
3. Traffic shape: Spiky mobile traffic needs Redis-backed rate limits. Steady B2B API usage may tolerate in-memory counters.
4. Aggregation needs: Heavy response merging favours KrakenD or a thin Node/BFF behind the gateway.
5. Migration stage: Still splitting a Laravel monolith? Start with path routing to extracted modules before full microservices. Read monolith to microservices migration for Laravel.

On Quick And Easy Nepalese Grocery, a Laravel eCommerce platform with delivery zones, a gateway-style edge was not day-one infrastructure. As checkout, inventory, and notification concerns split, consolidating auth and webhook URLs at one edge reduced deployment coordination. Start simple. Add gateway features when pain appears—not before.

How do you configure authentication and rate limiting at the gateway?

Authentication belongs at the gateway for external clients. Internal service-to-service calls should use mTLS or signed internal tokens—not the same public JWT the mobile app carries. Mixing those trust zones causes privilege escalation when a compromised service replays user tokens.

JWT validation at the edge

Most Laravel APIs issue JWTs via Passport or use Sanctum SPA tokens. Configure the gateway to validate signature, expiry, and issuer against your JWKS endpoint. Reject expired tokens with 401 before the request touches PHP-FPM workers.

# Traefik middleware excerpt (forwardAuth to Laravel)
http:
  middlewares:
    api-auth:
      forwardAuth:
        address: "http://auth-svc.internal/api/gateway/verify"
        authResponseHeaders:
          - X-User-Id
          - X-User-Roles
  routers:
    orders:
      rule: "PathPrefix(`/api/v1/orders`)"
      middlewares:
        - api-auth
      service: order-svc

Your Laravel verification endpoint returns 200 with identity headers on success. Keep it fast—cache JWKS keys in Redis. Full security coverage belongs in your API security checklist, including header trust boundaries and webhook signature validation.

Rate limiting strategies

Apply limits at three levels: global (protect infrastructure), per-client API key (fair usage tiers), and per-route (expensive endpoints like PDF generation). Redis 8.10 as a shared counter store works across multiple gateway instances. Laravel also offers route-level throttling—useful inside services but not a substitute for edge limits. See rate limiting and throttling in Laravel for app-layer patterns that complement the gateway.

# Kong rate-limiting with consumer tiers
consumers:
  - username: partner-acme
    keyauth_credentials:
      - key: acme-live-key-xxx

plugins:
  - name: rate-limiting
    consumer: partner-acme
    config:
      minute: 1000
      hour: 20000
      policy: redis

Return standard headers: X-RateLimit-Limit, X-RateLimit-Remaining, and Retry-After on 429 responses. Mobile clients and partner SDKs depend on predictable shapes. Test limit boundaries with JSON formatter tools when debugging aggregated error payloads.

Idempotency and versioning at the boundary

Payment and booking APIs should accept Idempotency-Key headers at the gateway and forward them unchanged. The gateway should not deduplicate—it lacks business context. Forward the header and let the payment service enforce semantics. Read idempotency key implementation for the full pattern. Version paths (/v1, /v2) route to different upstream groups during migration. See Laravel API versioning strategy and versioning strategies compared.

What are common API gateway mistakes in production?

Gateways fail in predictable ways. I've debugged these during production deployments on shared EC2 infrastructure where multiple Laravel sites run behind the same edge layer.

Fat gateway anti-pattern

Do not implement pricing rules, inventory checks, or legal document validation in gateway plugins. The gateway orchestrates and protects. Business rules stay in domain services written in Laravel 13.x or Symfony 8.1 where you have tests, migrations, and audit trails. A gateway Lua script that calculates VAT for Nepal IRD compliance will become unmaintainable within one fiscal year.

High availability and config drift

Run at least two gateway instances behind a load balancer. Store declarative config in Git. Apply it through CI—the same GitLab CI pipeline that deploys your Laravel app should validate and push gateway YAML. I've seen manual Kong admin API edits lost during server rebuilds. Treat gateway config like application code.

Timeout and body-size alignment

If your document upload service allows 50 MB payloads, the gateway must match. Default 1 MB limits cause silent failures on legal-tech portals where clients upload scanned affidavits. Align timeouts: gateway read timeout must exceed upstream processing time for slow report generation.

Testing the edge layer

Contract tests between gateway routes and upstream OpenAPI specs catch drift early. Include gateway routes in your Postman or Newman collections. Run smoke tests after every deploy. For broader QA workflow, see testing and optimization services and API testing with Postman and Newman.

When building new REST surfaces in Laravel, pair gateway rollout with building RESTful APIs with Laravel. Document public contracts with OpenAPI so the gateway team and service team share one source of truth—see API documentation with Redoc and Swagger UI.

For enterprise programmes needing dedicated gateway design, enterprise application development covers multi-service architectures from planning through production hardening. Client portals like Mijar Law Associates benefit from stable webhook and OAuth callback URLs managed at the gateway regardless of which internal service handles the workflow.

Official references worth bookmarking: the AWS API Gateway developer guide for managed patterns, and the Kong Gateway documentation for self-hosted plugin configuration. The Microservices.io API Gateway pattern page gives a concise architectural summary from Chris Richardson's catalog.

Key Takeaways

• Place API gateways for microservices at the public edge so clients use one URL while internal services stay private.
• Handle auth, rate limits, TLS, and routing at the gateway; keep business logic in Laravel or Symfony services.
• Choose Kong, Traefik, AWS API Gateway, or KrakenD based on hosting, team size, and aggregation needs—not hype.
• Store gateway config in Git, run multiple instances, and align timeouts and body limits with upstream services.
• Pair the gateway with observability—request IDs, access logs, and Prometheus metrics—from day one.
• Start with path routing during monolith extraction; add plugins as cross-cutting pain appears.

People Also Ask

Is an API gateway the same as a load balancer?

No. A load balancer distributes traffic across identical instances of one service. An API gateway routes different paths to different services, validates tokens, transforms requests, and applies per-client policies. Many setups use both—a cloud load balancer in front of gateway instances, then path-based routing to microservices.

Do I need an API gateway for three microservices?

Three services can work without a dedicated gateway if you accept duplicated auth middleware and multiple public endpoints. Once you add mobile clients, partner API keys, or webhook stability requirements, a gateway pays for itself. A single Traefik or Nginx instance on your existing VPS is enough to start.

Can Laravel be an API gateway?

Laravel can proxy requests via HTTP client middleware, but it is a poor dedicated gateway. PHP-FPM workers are heavier per connection than Nginx, Kong, or Traefik. Use Laravel to issue and verify tokens; use a reverse proxy at the edge for routing and rate limiting. Laravel 13.x excels at domain APIs behind the gateway, not as the gateway itself.

How does an API gateway differ from a service mesh?

The gateway manages north-south traffic from external clients into the cluster. A service mesh manages east-west traffic between internal services with sidecars, mTLS, and retries. Production systems often use both—the gateway for clients, Istio or Linkerd for internal calls.

Ship a gateway layer your microservices can grow into

API gateways for microservices are not optional complexity—they are how you keep client integrations stable while backend teams deploy independently. Start with routing and TLS, add auth and rate limits when traffic justifies them, and keep business rules out of the edge. Whether you are extracting modules from a Laravel monolith or wiring payment webhooks for a Nepal eCommerce launch, the gateway is the contract your clients depend on.

Need help designing the edge layer, public API surface, or migration path for your services? Contact us to plan gateway architecture, API development, and production deployment together—or browse the portfolio for platforms already running on these patterns.