Load Balancing & Traffic Management

## ROLE
You are a traffic engineering specialist who designs load balancing solutions for high-traffic applications serving global audiences.

## OBJECTIVE
Design a load balancing and traffic management strategy for [APPLICATION] handling [PEAK TRAFFIC] across [REGIONS] with [AVAILABILITY TARGET].

## TASK

### Load Balancer Architecture
- Layer 4 (TCP/UDP): high performance, protocol-agnostic (NLB, HAProxy)
- Layer 7 (HTTP/HTTPS): content-based routing, SSL termination (ALB, Nginx, Envoy)
- Global load balancing: DNS-based or anycast for geographic distribution
- Internal load balancing: service-to-service traffic within infrastructure

### Routing Algorithms
- Round-robin: simple, even distribution (default for stateless services)
- Least connections: route to server with fewest active connections
- Weighted: assign more traffic to more powerful instances
- IP hash: consistent routing for the same client
- Latency-based: route to fastest responding backend

### Health Checks
- Passive: detect failures from client request results
- Active: periodic probes to backend endpoints
- Deep health: check dependencies, not just process liveness
- Graceful shutdown: drain connections before removing instance
- Health check endpoints: /health for basic, /ready for full readiness

### Session Management
- Stateless design: preferred — no affinity needed
- Sticky sessions: when state must reside on specific server
- Distributed session store: Redis-backed sessions for true scalability
- JWT tokens: client-side state, no server affinity needed

### Auto-Scaling Integration
- Scaling triggers: CPU, memory, request count, queue depth, custom metrics
- Scale-up policy: aggressive (don't make users wait)
- Scale-down policy: conservative (avoid flapping)
- Warm pool: pre-initialized instances for instant capacity
- Predictive scaling: schedule-based for known traffic patterns

### Resilience
- Multi-AZ deployment: survive availability zone failure
- Multi-region: active-active or active-passive for regional failure
- DDoS mitigation: rate limiting, connection limits, cloud DDoS protection
- Failover: automatic and manual failover procedures
- Chaos engineering: regularly test failure scenarios

## OUTPUT FORMAT
Traffic management design with load balancer configuration, routing rules, health check specifications, and scaling policies.

## CONSTRAINTS
- Load balancer must not become a bottleneck or single point of failure
- SSL/TLS configuration must follow current security best practices
- Include cost modeling: traffic costs, LB instance costs, cross-AZ data transfer
- Plan for zero-downtime deployments through LB integration
- Monitor LB health itself, not just backend health