API Gateways

An API gateway is the single entry point for all client requests. It handles cross-cutting concerns like authentication, rate limiting, and routing, keeping your backend services focused on business logic.

Why API Gateways Matter

Without an API gateway:

• Each service implements authentication separately
• Clients need to know about multiple service endpoints
• Cross-cutting concerns are duplicated
• Protocol translation is handled per-service

With an API gateway:

• Single entry point simplifies client code
• Centralized authentication and authorization
• Consistent rate limiting and logging
• Protocol flexibility (REST to gRPC, etc.)

Core Functions

API Gateway Options

Architecture Patterns

Basic Gateway Pattern

Single gateway for all traffic.

              ┌→ User Service
Client → Gateway → Order Service
              └→ Product Service

Pros: Simple, single point of control Cons: Can become a bottleneck, single point of failure

Backend for Frontend (BFF)

Separate gateways for different clients.

Web App → Web BFF Gateway ─┐
                           ├→ Backend Services
Mobile App → Mobile BFF Gateway ─┘

Pros: Optimized per client, independent evolution Cons: More infrastructure, potential duplication

Federated Gateway

Multiple gateways with a unified entry point.

              ┌→ Orders Gateway → Order Services
Client → Edge Gateway → Users Gateway → User Services
              └→ Products Gateway → Product Services

Pros: Team autonomy, better scaling Cons: Complex routing, coordination challenges

Web App → Web Gateway ───────┐
                             │
iOS App → Mobile Gateway ────┼→ Shared Backend Services
                             │
Android App → Mobile Gateway ┘

Authentication Patterns

JWT Validation

Gateway validates JWT tokens without calling auth service.

1. Client sends: Authorization: Bearer <jwt>
2. Gateway validates JWT signature (using public key)
3. Gateway extracts claims (user_id, roles)
4. Gateway adds claims to headers for backend
5. Backend trusts headers from gateway

Pros: Fast (no auth service call), stateless Cons: Can't revoke tokens instantly

API Key Authentication

Gateway looks up API key in database/cache.

1. Client sends: X-API-Key: abc123
2. Gateway looks up key in Redis/database
3. Gateway gets associated user, permissions, rate limits
4. Gateway enforces rate limit, routes request

Pros: Easy revocation, flexible metadata Cons: Database lookup per request (mitigate with cache)

OAuth Token Introspection

Gateway validates tokens with auth server.

1. Client sends: Authorization: Bearer <opaque_token>
2. Gateway calls auth server: POST /introspect
3. Auth server returns: {active: true, user_id: 123, scope: "read write"}
4. Gateway caches result briefly, routes request

Pros: Real-time validation, works with opaque tokens Cons: Extra latency, auth server dependency

Request Transformation

Gateways can modify requests and responses.

Request Enrichment

# Incoming request
GET /api/orders/123
Authorization: Bearer <jwt>

# After gateway processing
GET /internal/orders/123
X-User-ID: user_456
X-Tenant-ID: tenant_789
X-Request-ID: req_abc

Response Aggregation

Combine multiple service responses.

# Client requests user profile
GET /api/profile

# Gateway calls multiple services:
GET /user-service/users/123
GET /order-service/users/123/stats
GET /recommendation-service/users/123/recommendations

# Gateway combines into single response
{
  "user": {...},
  "orderStats": {...},
  "recommendations": [...]
}

Protocol Translation

Client (REST) → Gateway → Backend (gRPC)

Gateway can translate between protocols, allowing:

• External REST API
• Internal gRPC for performance
• WebSocket to HTTP long-polling fallback

Level-Based Expectations

Common Concerns

Gateway as Single Point of Failure

Mitigation:

• Multiple gateway instances behind load balancer
• Health checks and automatic failover
• Regional redundancy
• Graceful degradation

Gateway as Bottleneck

Mitigation:

• Horizontal scaling (stateless gateways)
• Efficient routing (avoid complex logic)
• Caching at gateway level
• Offload to CDN where possible

Gateway Coupling

Mitigation:

• Keep gateway thin (routing, auth, not business logic)
• Use service discovery for dynamic routing
• Version APIs to allow independent evolution

Common Interview Scenarios

"How would you handle authentication in a microservices architecture?"

"I'd centralize authentication at the API gateway. The gateway validates JWT tokens using the auth service's public key—no network call needed for validation. It extracts user claims and passes them to backend services via trusted headers. Backend services don't validate tokens; they trust the gateway. For token revocation, I'd use short-lived tokens with refresh tokens, or maintain a small deny-list in Redis."

"How do you prevent the gateway from becoming a bottleneck?"

"Several strategies: First, keep the gateway stateless so it scales horizontally. Second, minimize gateway logic—routing and auth only, no business logic. Third, cache authentication results briefly. Fourth, use efficient routing (hash maps, not regex chains). Fifth, consider BFF pattern to distribute load across multiple gateways."

"When would you use multiple gateways?"

"I'd use multiple gateways (BFF pattern) when clients have significantly different needs. For example, mobile apps might need aggregated endpoints to reduce round trips, while web apps can make multiple calls. Or when teams need autonomy—the orders team can own the orders gateway independently. For internal service-to-service communication, I might skip the gateway entirely or use a service mesh."

What's Next

API gateways handle request routing and cross-cutting concerns. Next, we'll look at search systems for full-text search and complex query needs.