Q: Explain Load Balancer, Reverse Proxy, and Ingress with real architecture examples.

A Load Balancer distributes incoming network traffic across multiple backend servers to prevent overload, maximize throughput, and ensure high availability through continuous health checks.

# AWS CLI creating a high-throughput Layer 4 Network Load Balancer (NLB)
aws elbv2 create-load-balancer \
  --name prod-l4-nlb \
  --type network \
  --subnets subnet-01 subnet-02

• Layer 4 Load Balancer (NLB, HAProxy TCP): Operates at the transport layer (TCP/UDP). It routes raw packets without inspecting HTTP payloads or headers, providing ultra-low latency (millions of requests/sec).
• Layer 7 Load Balancer (AWS ALB, F5 BIG-IP): Operates at the application layer. It inspects HTTP/HTTPS headers, cookies, and URIs, enabling path-based routing, TLS termination, and sticky sessions.
• Real Production Example: An AWS NLB sitting in front of a banking payment API handling millions of concurrent raw TCP transactions.

A Reverse Proxy sits in front of web servers and intercepts client requests before forwarding them to backend origins. Unlike a forward proxy (which shields clients), a reverse proxy shields and optimizes backend servers.

# Nginx Reverse Proxy configuration snippet
server {
    listen 443 ssl http2;
    server_name api.example.com;

    location /auth/ {
        proxy_pass http://auth_service_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_cache api_cache;
    }
}

• Core Capabilities: SSL/TLS termination, static asset caching, Gzip/Brotli response compression, rate limiting, and masking origin server IP addresses.
• Real Production Example: Nginx or Envoy proxying traffic to Node.js applications, caching read-heavy catalog endpoints, and terminating SSL certificates.

In Kubernetes, Ingress is not a physical server; it is a declarative API resource that configures an Ingress Controller (a specialized reverse proxy such as ingress-nginx, Traefik, or Envoy) to route external traffic to internal ClusterIP Services.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: billing-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/limit-rps: "50"
spec:
  ingressClassName: nginx
  rules:
  - host: billing.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: billing-api
            port:
              number: 80

• Ingress Resource vs Ingress Controller: The Ingress resource is just YAML configuration stored in etcd. The Ingress Controller is the active daemon watching the API and generating Nginx/Envoy configs dynamically.
• Real Production Example: Nginx Ingress Controller managing SSL certs via cert-manager and routing 50+ microservices on a single shared Cloud Load Balancer.

Comprehensive architectural decision matrix comparing load balancer reverse proxy ingress components across essential production criteria:

In enterprise cloud architectures, these three components do not compete; they complement each other in a layered defence-in-depth traffic hierarchy.

• Layer 1 (Cloud Load Balancer): AWS NLB receives public internet traffic on port 443, handles DDoS mitigation, and distributes traffic across Availability Zones.
• Layer 2 (Ingress Controller / Reverse Proxy): Ingress-Nginx pods receive traffic from the NLB, terminate TLS, validate JWT auth tokens, and evaluate URL path routes.
• Layer 3 (Kubernetes Service & Pod): Traffic flows to the target Kubernetes Service ClusterIP and enters the application pod.