Nginx load balancing with SSL, failover, and monitoring

Context

This documented architecture exercise uses Nginx as the public entry point for two backend application servers. It explores secure request handling, distribution across backends, failover behaviour, and logs as an operational signal.

Architecture

The request path is deliberately simple: client traffic reaches Nginx, TLS is terminated at the edge, and Nginx distributes requests to backend services using an upstream definition. Backend failure settings provide a bounded response to unavailable nodes.

upstream backend_servers {
  server 10.0.0.2 max_fails=3 fail_timeout=30s;
  server 10.0.0.3 max_fails=3 fail_timeout=30s;
}

Technical decisions

• Keep the public entry point explicit and auditable.
• Terminate encrypted traffic at a controlled edge.
• Treat logging and failure handling as part of the architecture, not an afterthought.
• Avoid presenting this exercise as a client deployment or claiming unverified production outcomes.

Lessons carried forward

High-availability patterns become useful when their operating model is clear: what is observed, how failure is detected, and who owns the response. The same discipline applies to infrastructure beyond a load balancer.