API Gateway Pattern

Also Known As

TL;DR

Explanation

An API Gateway sits between clients and backend services providing: request routing, authentication and JWT validation, rate limiting, SSL termination, request/response transformation, caching, logging, and circuit breaking. Examples: Kong, AWS API Gateway, Nginx as a gateway, Traefik. The gateway decouples clients from service topology — backends can be reorganised without client changes. For PHP monoliths evolving toward microservices, a gateway enables gradual strangler fig migration. Trade-off: the gateway is a potential single point of failure and performance bottleneck — it must be highly available, low-latency, and horizontally scaled.

Diagram

flowchart LR
    C1[Mobile Client] & C2[Web Client] & C3[Partner API] --> GW[API Gateway]
    subgraph Gateway responsibilities
        GW --> AUTH[Auth / JWT verify]
        GW --> RL[Rate Limiting]
        GW --> LOG[Logging / Tracing]
        GW --> TRANS[Transform / Version]
    end
    AUTH & RL & LOG & TRANS --> MS1[User Service]
    AUTH & RL & LOG & TRANS --> MS2[Order Service]
    AUTH & RL & LOG & TRANS --> MS3[Payment Service]
style GW fill:#d29922,color:#fff
style AUTH fill:#f85149,color:#fff
style RL fill:#d29922,color:#fff

Common Misconception

Why It Matters

Common Mistakes

• Putting business logic in the gateway — it should handle infrastructure concerns, not domain rules.
• Not handling gateway failures gracefully — a gateway outage becomes a total outage; circuit breakers are needed.
• Using a gateway for internal service-to-service calls — adds latency with no benefit; use service mesh or direct calls.
• Not monitoring the gateway separately — it is a critical single point of failure.

Avoid When

• Single-service architectures — a gateway in front of one service is just a reverse proxy with extra steps.
• The gateway becomes a bottleneck — all traffic funnelled through one gateway is a single point of failure.
• Putting business logic in the gateway — it should route and cross-cut, not implement domain rules.
• High-latency budgets are tight — every request pays the gateway roundtrip overhead.

When To Use

• Microservice architectures where clients should not call individual services directly.
• Centralising cross-cutting concerns: auth, rate limiting, logging, CORS, SSL termination.
• Backend-for-frontend patterns where the gateway aggregates multiple service responses.
• Exposing a unified API surface to external clients while the internal architecture evolves.

Code Examples

// Business logic in gateway config — wrong layer:
// gateway.yaml:
routes:
  - path: /orders
    plugin: custom-discount-calculator  # Business logic belongs in the order service
    auth: jwt
    rate_limit: 100/min

// API Gateway pattern — single entry point for all clients
// Handles: routing, auth, rate limiting, logging, SSL termination

// nginx as simple API gateway:
server {
    listen 443 ssl;

    # Route to microservices
    location /api/orders/ {
        proxy_pass http://orders-service:8001/;
        proxy_set_header X-Forwarded-For \$remote_addr;
    }
    location /api/users/ {
        proxy_pass http://users-service:8002/;
    }

    # Rate limiting at gateway
    limit_req_zone \$binary_remote_addr zone=api:10m rate=100r/m;
    limit_req zone=api burst=20 nodelay;
}

// Laravel as API gateway with auth:
Route::middleware(['auth:api', 'throttle:100,1'])->group(function() {
    Route::any('/orders/{path}', [GatewayController::class, 'forward'])->where('path', '.*');
});

References

• ↗ https://microservices.io/patterns/apigateway.html

Tags

Related Terms