API Gateway & Reverse Proxy
The Image Service That Made Every Origin Server Sweat
Test your architecture intuition: Pitch a 7-axis solution, survive two aggressive reviewer objections, and inspect the staff-level Teacher Gold Answer.
1. What It Is & Why It Exists
The Core Problem: Direct Client-to-Microservice Chaos
In a distributed microservices ecosystem, allowing mobile apps and browser clients to communicate directly with individual backend microservices introduces critical architectural vulnerabilities:
- Security Attack Surface: Exposing hundreds of internal private IP endpoints directly to the public internet.
- Duplicated Cross-Cutting Logic: Every microservice team must independently build and maintain authentication (JWT validation), rate limiting, SSL/TLS certificates, CORS headers, and audit logging.
- Protocol & Network Friction: Mobile clients on high-latency cellular networks must make 15 separate roundtrips to hydrate a single page (the "Chatty Client" problem), while internal services communicate over high-performance binary gRPC.
The First-Principles Solution: Reverse Proxy & API Gateway
An API Gateway is a reverse proxy positioned at the network edge that intercepts all incoming client traffic, terminates TLS, enforces authentication, quotas, and security policies, and intelligently routes requests to downstream internal services.
Synthesizing vector architecture diagram...
Follow one request from the top. Route 53 points the domain at CloudFront, which sends the user to a nearby edge and terminates TLS close to the user, and WAF drops attacks and known-bad traffic, so only clean requests reach the gateway. In the "Gateway Cross-Cutting Policy Engine" panel, the gateway applies the checks every service would otherwise re-implement: validating the JWT (with a cached authorizer result), enforcing the rate limit, skipping unhealthy backends (outlier detection) and capping what a failing backend can tie up (circuit breaking). Only then is the request routed to the right service in the "Internal VPC Private Subnet" panel, often translated from HTTP to gRPC. Putting shared concerns in the gateway keeps each service small, but the gateway must then scale and stay highly available, because every request passes through it.
2. Core Mechanics: Layer 4 vs. Layer 7 Ingress
Synthesizing vector architecture diagram...
Comprehensive Comparison Matrix
| Ingress Proxy | OSI Layer | Routing Criteria | Latency Overhead | Memory Footprint | Primary Production Fit |
|---|---|---|---|---|---|
| Amazon API Gateway | Layer 7 | Method + Path (/v1/orders) | Highest of these (managed service; measure Latency minus IntegrationLatency) | Serverless | Serverless architectures, AWS Lambda, external partner APIs |
| Envoy Proxy | Layer 7 | Path, Headers, Query params, gRPC | Low (one proxy hop you run) | Low (C++ event loop) | Kubernetes Service Mesh (Istio), high-throughput internal routing |
| AWS ALB | Layer 7 | Host header, Path, Query parameters | Low (managed L7 hop) | Managed | General microservices, ECS container fleets, web applications |
| AWS NLB | Layer 4 | TCP / UDP / TLS ports | Lowest (no HTTP parsing) | Managed | Ultra-high throughput gaming, IoT streaming, static IP requirements |
| Nginx | Layer 7 | URI, Regular Expressions | Low (one proxy hop you run) | Low (C event-driven) | Static asset reverse proxy, edge caching |
Unlock Complete Architecture & Production Runbooks
You have explored the free architectural preview (~45%). Spend 1 Coin to unlock the remaining 5 production deep-dive sections for a full 24 hours.