Why Use Service Registry & Discovery When Nginx Already Handles Load Balancing?

The author starts from a popular Zhihu question asking why service registries are needed when Nginx can already perform load balancing.

Nginx Load Balancing Limitations

Nginx's upstream list is static and must be written in the configuration file. For example:

upstream order-service {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

server {
    location /api/orders {
        proxy_pass http://order-service;
    }
}

When the number of instances is small and rarely changes, this works, but the static list becomes a problem as soon as instances are added, removed, or fail. Each change requires editing the config and running nginx -s reload on every Nginx node, which is cumbersome in a micro‑service environment with dozens of services and frequent scaling.

Although Nginx has a passive health‑check mechanism that temporarily removes a server after consecutive errors, it only reacts after real traffic fails, so a faulty instance may continue receiving requests until a failure is observed.

Service Registry Mechanism

Service instances continuously send heartbeats (default every 5 seconds) to the registry. If a heartbeat is missed, the registry immediately removes the instance from its list. Consumers fetch the updated list and no real traffic is needed to detect failures. Nginx Plus offers an active nginx_upstream_check_module, but it adds operational overhead without solving the core problem.

Elastic Scaling Not Feasible with Nginx

In cloud environments, pods are created and destroyed dynamically (e.g., K8s scaling from 3 to 20 instances). Each pod receives a new IP, so the Nginx upstream must be updated for every change, which cannot be automated reliably. Manual scripts and reloads cannot keep up with rapid scaling.

Service‑to‑Service Calls: Nginx vs Client‑Side Load Balancing

When all internal calls go through Nginx, the request path becomes ServiceA → Nginx → ServiceB. This adds an extra network hop, increases latency, and makes Nginx a potential bottleneck. With a registry, each service obtains the instance list and performs client‑side load balancing (e.g., Spring Cloud LoadBalancer), eliminating the extra hop.

Features Enabled by a Registry

Gray release: instances of version v2 are tagged with version=v2; consumers route a small percentage of traffic based on this tag, whereas Nginx would need split_clients or Lua scripts and a reload for each change.

Region‑aware routing: instances carry a region metadata (e.g., "shanghai" or "beijing"); consumers can route requests to the nearest region without complex Nginx geo configuration.

Dynamic weight adjustment: changing an instance's weight in the registry takes effect instantly, while Nginx requires editing the weight parameter and reloading.

{
    "serviceName": "order-service",
    "ip": "192.168.1.10",
    "port": 8080,
    "metadata": {
        "version": "v2",
        "region": "shanghai",
        "env": "gray",
        "weight": 80
    }
}

Scenarios Where Nginx Still Shines

Nginx remains essential as the external entry point for user traffic, handling SSL termination, rate limiting, WAF, and other edge functions that no registry can replace.

Conclusion

Nginx and service registries solve different problems: Nginx forwards external requests, while registries provide dynamic discovery and health awareness for internal micro‑service communication. In small, static deployments Nginx alone suffices; in large, rapidly changing environments a registry is indispensable.