Architecture Pattern - API Gateway¶

Overview¶

The API Gateway pattern provides a single entry point for client requests to backend microservices. It handles cross-cutting concerns like authentication, rate limiting, request routing, protocol translation, and response aggregation - simplifying client interactions with distributed systems.

Pattern Description¶

Problem¶

• Clients need to interact with multiple microservices
• Each service may use different protocols, authentication mechanisms, and data formats
• Direct client-to-service communication creates tight coupling
• Cross-cutting concerns (auth, logging, rate limiting) are duplicated across services

Solution¶

Place an API Gateway between clients and backend services that: - Routes requests to appropriate backend services - Aggregates responses from multiple services - Handles authentication and authorization centrally - Applies rate limiting and throttling - Transforms protocols and data formats - Provides a stable API contract regardless of backend changes

flowchart LR
  W[Web client] --> AG
  M[Mobile client] --> AG
  P[Partner / B2B] --> AG
  AG[API gateway<br/>auth, throttle, route, transform]
  AG --> S1[Order service<br/>REST]
  AG --> S2[User service<br/>gRPC]
  AG --> S3[Catalog service<br/>GraphQL]
  AG --> S4[Search service]
  AG -. emits .-> LOG[Logs / metrics / traces]

When to Use¶

• Microservices architectures with multiple backend services
• Mobile/web applications needing optimized API responses
• Multi-tenant SaaS platforms requiring per-tenant controls
• Public APIs requiring monetization and developer portals
• Systems needing protocol translation (REST to gRPC, SOAP to REST)

When to Avoid¶

• Simple monolithic applications with a single backend
• Internal service-to-service communication (use service mesh instead)
• Real-time streaming workloads (use direct connections)
• When latency sensitivity prohibits an additional network hop

Architecture Components¶

Core Components¶

                    ┌─────────────────┐
   Clients ──────>  │   API Gateway    │
   (Web, Mobile,    │                  │
    IoT, Partners)  │  - Auth          │
                    │  - Rate Limit    │
                    │  - Routing       │
                    │  - Transform     │
                    │  - Cache         │
                    └────────┬─────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
         ┌────▼────┐   ┌────▼────┐   ┌────▼────┐
         │Service A │   │Service B │   │Service C │
         │(Orders)  │   │(Users)   │   │(Products)│
         └──────────┘   └──────────┘   └──────────┘

Gateway Responsibilities¶

Cloud Implementation¶

AWS Implementation¶

AWS Architecture:

CloudFront -> WAF -> API Gateway -> Lambda Authorizer
                                 -> Lambda (backend)
                                 -> ALB -> ECS/EKS
                                 -> Step Functions
                                 -> DynamoDB (direct integration)

Azure Implementation¶

Azure Architecture:

Azure Front Door -> WAF -> API Management -> Azure Functions
                                          -> App Service
                                          -> AKS
                                          -> Logic Apps

Google Cloud Implementation¶

GCP Architecture:

Cloud CDN -> Cloud Armor -> Global LB -> API Gateway/Apigee -> Cloud Run
                                                             -> Cloud Functions
                                                             -> GKE

Design Patterns¶

Backend for Frontend (BFF)¶

Deploy separate API gateways optimized for each client type.

API Composition / Aggregation¶

The gateway aggregates responses from multiple services into a single response.

Client Request: GET /order-summary/123

Gateway calls in parallel:
  - Order Service: GET /orders/123
  - User Service: GET /users/456
  - Product Service: GET /products/789

Gateway response: Combined order + user + product data

Gateway Offloading¶

Move cross-cutting concerns from services to the gateway.

API Versioning Strategies¶

Implementation per Cloud¶

Security Best Practices¶

Defense in Depth¶

Common Security Patterns¶

1. Token Relay - Gateway validates JWT, passes claims to backend via headers
2. Token Exchange - Gateway exchanges external token for internal service token
3. API Key + OAuth - API key for identification, OAuth for authorization
4. mTLS Backend - TLS between gateway and services with client certificates
5. Request Signing - Gateway signs requests for backend verification

Performance Optimization¶

Monitoring and Observability¶

Certification Exam Focus Areas¶

AWS¶

• API Gateway REST vs HTTP API vs WebSocket API differences
• Lambda authorizer types (token vs request)
• Usage plans, API keys, and throttling configuration
• Stage variables and canary deployments
• VPC link for private integrations

Azure¶

• APIM tiers (Consumption, Developer, Basic, Standard, Premium)
• Policy expressions and policy scopes (inbound, backend, outbound, on-error)
• Products, subscriptions, and developer portal
• Self-hosted gateway for hybrid/multi-cloud
• Backend circuit breaker and retry policies

Google Cloud¶

• Apigee vs API Gateway decision criteria
• Apigee proxy flow (PreFlow, Conditional Flows, PostFlow)
• API products, developer apps, and monetization
• Cloud Endpoints for gRPC and OpenAPI
• ESP (Extensible Service Proxy) for authentication

Documentation Links¶

• AWS API Gateway: https://docs.aws.amazon.com/apigateway/latest/developerguide/
• Azure API Management: https://learn.microsoft.com/en-us/azure/api-management/
• Google Apigee: https://cloud.google.com/apigee/docs
• Google API Gateway: https://cloud.google.com/api-gateway/docs
• API Gateway Pattern (Microsoft): https://learn.microsoft.com/en-us/azure/architecture/microservices/design/gateway

Key Takeaways¶

1. The API Gateway pattern is essential for microservices - it simplifies client communication and centralizes cross-cutting concerns
2. Choose between managed (API Gateway, APIM, Apigee) vs self-hosted (Kong, NGINX, Envoy) based on operational maturity
3. BFF pattern prevents a single gateway from becoming a bottleneck by optimizing per client type
4. Always implement rate limiting, authentication, and WAF at the gateway level
5. Cache aggressively at the gateway - most read-heavy APIs benefit significantly
6. Monitor gateway latency carefully - it adds an extra hop to every request
7. API versioning strategy should be decided early and applied consistently