Global Load Balancers, Local Load Balancers, and API Gateways

In modern distributed systems, handling incoming client traffic efficiently, securely, and reliably is critical. As applications grow from single-server architectures to multi-region, microservice-based deployments, traffic management is split into a tiered routing model.

Understanding how Global Load Balancers (GLB), Local Load Balancers (LLB), and API Gateways differ and interact is a core requirement for designing resilient systems.

The Tiered Traffic Routing Flow

When a user interacts with a web or mobile application, their request typically flows through three distinct layers before reaching the actual backend service:

1. Global Load Balancer (GLB)

A Global Load Balancer operates at the entry point of the internet (often at the Edge/DNS level). Its primary purpose is to route client requests to the most appropriate datacenter or cloud region.

Core Mechanisms

• DNS-Based Routing: The load balancer returns the IP address of the closest region to the client (e.g., AWS Route 53, Cloudflare DNS).
• Anycast IP Routing: Multiple servers across the globe share a single IP address. BGP (Border Gateway Protocol) routes the traffic to the closest server (e.g., Cloudflare Anycast CDN, Google Cloud GLB).
• Latency-Based Routing: Routes traffic based on the lowest round-trip time (RTT) from the client's location.
• Geo-Fencing / Geo-Routing: Redirects users to specific regions based on country or language preferences (often for regulatory compliance like GDPR).

Key Functions

• Multi-Region High Availability & Disaster Recovery: If a region fails completely, GLB redirects all new requests to healthy standby regions.
• DDoS Protection at the Edge: Absorbs malicious traffic at the Edge network before it hits backend application servers.
• Content Delivery Network (CDN) Integration: Caches static files globally at Edge locations.

Popular Technologies

• Cloudflare Global Load Balancer
• AWS Route 53 (DNS Traffic Flow)
• Google Cloud External HTTP(S) Load Balancing (Anycast-based L7 GLB)
• Akamai GTM (Global Traffic Management)

2. Local Load Balancer (LLB)

A Local Load Balancer operates within a single datacenter or virtual private cloud (VPC) region. Its primary objective is to distribute incoming traffic evenly across a pool of servers, containers, or virtual machines to prevent overloading any single resource.

Layers of Operation

• Layer 4 (L4) Load Balancing: Routes traffic based on IP address and TCP/UDP ports. It is extremely fast because it does not inspect the contents of the HTTP payload (e.g., AWS Network Load Balancer, HAProxy).
• Layer 7 (L7) Load Balancing: Operates at the application level. It parses the HTTP header, URL path, cookies, and body to make routing decisions (e.g., routing /api/v1/users to Server Pool A and /api/v1/checkout to Server Pool B).

Key Functions

• SSL/TLS Termination: Offloads CPU-intensive SSL decryption from backend servers, processing TLS at the load balancer level and communicating via HTTP with backend VMs.
• Backend Health Checks: Continuously pings local application servers. If one crashes, it is immediately removed from the rotation pool.
• Session Persistence (Sticky Sessions): Uses cookies or client IPs to ensure subsequent requests from a user go to the exact same backend server (useful for stateful applications).

Popular Technologies

• Software-based: NGINX, HAProxy, Envoy, Traefik
• Cloud native: AWS Application Load Balancer (ALB), AWS Network Load Balancer (NLB)
• Hardware-based: F5 BIG-IP, Citrix ADC (NetScaler)

3. API Gateway

An API Gateway acts as the single point of entry for all API consumers (mobile apps, web apps, third-party clients). Unlike a traditional load balancer which is focused on network metrics and server health, an API Gateway is application and business logic aware. It abstracts the complexity of underlying microservices.

Key Functions

• Authentication & Authorization: Validates JWT tokens, API keys, OAuth credentials, or basic authentication before forwarding the request to internal microservices.
• Rate Limiting & Throttling: Restricts the number of API calls a client can make per second/minute to prevent abuse, resource exhaustion, or DDoS attacks (e.g., allowing 100 requests/min for free tier, 5000 requests/min for premium tier).
• Request & Response Transformation: Standardizes payloads (e.g., translating a legacy SOAP XML backend to modern JSON REST API, or adding tracing headers).
• Protocol Translation: Translates client-facing protocols (HTTP REST, WebSockets) to internal communication protocols (gRPC, message queues like RabbitMQ).
• Centralized Logging, Metrics & Distributed Tracing: Tracks telemetry data, adds unique transaction IDs (X-Correlation-ID) to incoming headers for end-to-end tracing across microservices.
• API Versioning & Routing: Handles URL rewrites and routes traffic dynamically based on api versions (e.g., /v2/users -> user-service-v2).

Popular Technologies

• Open Source / Enterprise: Kong, Apache APISIX, Tyk, Envoy, KrakenD
• Cloud Services: AWS API Gateway, Azure API Management, Apigee (Google Cloud)

Comparative Matrix

Architectural Example: Putting It All Together

Let's look at how they collaborate in a real-world scenario (e.g., Netflix or an E-Commerce platform):

1. Client (User in Tokyo): Opens their mobile browser and requests api.example.com/checkout.
2. Global Load Balancer:
   • Receives the DNS request.
   • Recognizes the client is in Japan.
   • Returns the Anycast IP of the ap-northeast-1 (Tokyo) region.
3. Local Load Balancer (in Tokyo VPC):
   • The client's TCP handshake hits the Local Load Balancer.
   • The LLB terminates the SSL connection (HTTPS -> HTTP).
   • Based on the path /checkout, it routes the HTTP request to the API Gateway server pool.
4. API Gateway:
   • Intercepts the request.
   • Extracts the JWT token from the Authorization header and verifies it.
   • Applies a rate-limiting check (checks Redis: has this user exceeded 60 requests/minute?).
   • Finds that the checkout service requires a gRPC call internally. It translates the incoming JSON to gRPC.
   • Forwards the request to the checkout-microservice.