Load Balancer Misconfiguration — The Hidden Single Point of Failure

# ❌ IP hash — all users behind a corporate NAT hit server #1
upstream backend {
  ip_hash;
  server app1:3000;
  server app2:3000;
  server app3:3000;
}
# Corporate office with 10,000 employees → same IP → server #1 is HOT

# ✅ FIX: Use cookie-based stickiness (more even distribution)
upstream backend {
  server app1:3000;
  server app2:3000;
  server app3:3000;
}

# Sticky session via cookie
upstream backend {
  server app1:3000;
  server app2:3000;
  sticky cookie srv_id expires=1h path=/;
}

# ✅ BETTER FIX: Make your app stateless — eliminate stickiness need
# Store sessions in Redis, not in-process
# Then any server can handle any request
upstream backend {
  least_conn;  # Always route to server with fewest active connections
  server app1:3000;
  server app2:3000;
  server app3:3000;
}

# ❌ Health check hits wrong endpoint or wrong port
upstream backend {
  server app1:3000;
  check interval=3000 rise=2 fall=3 timeout=1000 type=tcp;
  # TCP check: just tests if port is open
  # But your app might be up but broken internally!
}

# ✅ Check actual application health
upstream backend {
  server app1:3000;
  check interval=3000 rise=2 fall=3 timeout=2000 type=http;
  check_http_send "GET /health HTTP/1.0\r\nHost: localhost\r\n\r\n";
  check_http_expect_alive http_2xx;
}

// Make your health check actually verify what matters
app.get('/health', async (req, res) => {
  try {
    // Check DB connectivity
    await db.query('SELECT 1')

    // Check Redis connectivity
    await redis.ping()

    // Check memory is OK
    const heapMB = process.memoryUsage().heapUsed / 1024 / 1024
    if (heapMB > 800) {
      return res.status(503).json({ status: 'unhealthy', reason: 'high memory' })
    }

    res.status(200).json({ status: 'healthy', heapMB: heapMB.toFixed(0) })
  } catch (err) {
    res.status(503).json({ status: 'unhealthy', error: err.message })
  }
})

# ❌ Nginx just stops sending to server immediately during deploy
# In-flight requests to that server are dropped!

# ✅ Kubernetes: configure connection draining
spec:
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      terminationGracePeriodSeconds: 60  # Give 60s to finish requests
      containers:
        - lifecycle:
            preStop:
              exec:
                command: ["sleep", "15"]  # Wait 15s before SIGTERM
                # This drains load balancer before shutdown starts

# Nginx: remove server from pool before stopping
# In nginx upstream, when a server is removed, in-flight requests finish
upstream backend {
  server app1:3000;
  server app2:3000 weight=1;  # Reduce weight to 0 before removing
}

# ❌ LB timeout shorter than app timeout
# LB gives up at 30s, but app was going to respond in 35s
# LB retries → double execution risk

upstream backend {
  server app1:3000;
  keepalive 32;
}

server {
  proxy_connect_timeout 5s;
  proxy_read_timeout 30s;    # LB timeout
  proxy_send_timeout 30s;
}

// ❌ App sets timeout to 60s — longer than LB's 30s
app.use((req, res, next) => {
  req.setTimeout(60_000)  // Never actually reached — LB cuts at 30s
  next()
})

# ✅ App timeout SHORTER than LB timeout
server {
  proxy_read_timeout 35s;  # LB: 35s
}

// App: 30s — gives LB time to get the error response
app.use((req, res, next) => {
  req.setTimeout(30_000, () => {
    res.status(504).json({ error: 'Request timeout' })
  })
  next()
})

# ❌ Round robin treats all servers equally
# But server #3 has half the RAM and is always overwhelmed
upstream backend {
  server app1:3000;   # 16GB RAM, 8 cores
  server app2:3000;   # 16GB RAM, 8 cores
  server app3:3000;   # 4GB RAM, 2 cores — gets same load!
}

# ✅ Weight based on capacity
upstream backend {
  server app1:3000 weight=4;  # Gets 4x the traffic
  server app2:3000 weight=4;
  server app3:3000 weight=1;  # Gets 1/9 of traffic
}

# ✅ Or least_conn — automatically sends to least loaded server
upstream backend {
  least_conn;
  server app1:3000;
  server app2:3000;
  server app3:3000;
}

# ✅ Slow start — gradually ramp new server instead of full traffic
upstream backend {
  server app1:3000 slow_start=30s;  # Ramp to full weight over 30s
  server app2:3000 slow_start=30s;
  server app3:3000;  # Existing server — no slow start
}

# Check nginx upstream status
curl http://localhost/nginx_status

# Check which servers are up/down
curl http://localhost/upstream_status

# Per-server request distribution (should be ~equal)
# If one server is getting 80% → check for stickiness or weight issues

// Log which server handled each request (for debugging)
app.use((req, res, next) => {
  res.setHeader('X-Served-By', os.hostname())
  next()
})

// Check distribution from logs
// Should see roughly equal distribution across hostnames

// ALB health check path must return 200
// Common mistake: returning 301/302 redirect
app.get('/health', (req, res) => {
  // ❌ Never redirect health checks
  // res.redirect('/api/health')

  // ✅ Always return 200 directly
  res.status(200).json({ status: 'ok' })
})

// ALB idle timeout vs app keepalive
// ALB default: 60s idle timeout
// Node.js default: 5s keepalive
// Fix: set Node.js keepalive > ALB idle timeout
const server = app.listen(3000)
server.keepAliveTimeout = 65_000    // Slightly more than ALB's 60s
server.headersTimeout = 66_000      // Must be > keepAliveTimeout