High-Availability Entry for Distributed Systems: From Single Point of Failure to VIP + Nginx Architecture

In production environments, a single point of failure in the ingress gateway is one of the most common and most critical problems.

If your system has only one ingress IP, and the machine corresponding to this IP goes down, what will happen?

The answer is: the entire service is unavailable until this machine recovers.

This is the fragility of the direct-connect Master IP architecture. Starting from this problem, this article will gradually introduce a high-availability entry solution using virtual IP + Nginx.

I. Problems with the Direct Connection Architecture

This direct-connection architecture looks very simple, but it has several fatal flaws:

Question	Description
single point of failure	Master is down, the entire system is unavailable.
Release immediately interrupts.	Service interruption during Master restart/upgrade
Unable to scale horizontally	There is only one ingress IP; adding more Workers cannot solve the ingress problem.
Product perception backend	Product A needs to know the Master IP, and switching machines requires changing the configuration.

This architecture is fine at the demo stage, but once it goes live, it's a time bomb.

II. Introducing Virtual IPs: From "Dead IPs" to "Floating IPs"

To address a single point of failure, the first idea is:Prepare an additional backup Master..

Here a key concept is introduced:Virtual IP (VIP).

VIP is not an IP bound to a specific physical machine, but a "floating" IP address. It drifts between the primary and standby machines:

• Normally, the VIP points to the Master primary node.

• The Master primary is down, and the VIP automatically points to the standby node.

For Product A, it always accesses 192.168.0.200, will never change. The backend switch is to it Completely transparent of.

This is Keepalived + VRRP protocol Things to do. We will elaborate in the next chapter on how VRRP implements heartbeat detection, priority preemption, and MAC address migration.

III. From VIP to a true “high-availability entry point”

VIP solved the Master single point of failure problem, but there is still one issue:The Master has to handle both scheduling and providing external services, so its responsibilities are too heavy..

A better approach is to add another layer of reverse proxy between the VIP and the backend services.

The role of Nginx in this architecture:

• Reverse proxy: Receives all requests and forwards them to the backend Master

• Health check Periodically probe whether the Master is alive and automatically remove faulty nodes.

• Load balancing: If there are multiple Masters, requests can be distributed.

But there is still one problem here:Nginx itself is also a single point of failure. If Nginx goes down, the entire system will also be unavailable.

Therefore, we also need to make the Nginx layer highly available—multiple Nginx nodes + VIP failover.

This is the complete "high-availability entry" architecture:

• Entry layer: VIP 192.168.0.200 As a fixed entry point, manage drift through Keepalived

• Proxy layer: Three Nginx nodes (192.168.0.201,192.168.0.202,192.168.0.203), responsible for reverse proxy and health checks

• Business layer: Master primary-standby cluster, processes actual business requests

VIP drifts among three Nginx nodes via Keepalived. If any Nginx node goes down, the VIP automatically switches to another node, and Product A is completely unaware.

IV. What problems does this architecture solve?

Question	Direct-connect architecture	VIP + Nginx architecture
Master is down	❌ Site-wide unavailable	✅ Nginx Automatically Removes Faulty Master
Nginx is down	—	✅ VIP failover to standby Nginx
Master release upgrade	❌ Service shutdown required	✅ Remove nodes one by one and perform a rolling upgrade
Product perception of backend changes	❌ Need to change the configuration	✅ Access VIP forever 192.168.0.200
Horizontal scaling	❌ Ingress IP is the bottleneck	✅ The Nginx layer can be scaled

V. Scope of Application of This Architecture

This solution is not a silver bullet, but in many scenarios it is the best choice:

Scene	Applicability
Private deployment	✅ The VIP plan is the simplest and most reliable.
Distributed system in a self-built data center	✅ When there is no cloud vendor's LB service
Traditional applications that require a fixed entry point	✅ The product has a strong dependency on IP
Home/laboratory environment	✅ used in this article 192.168.0.0/24 Network segment fully compatible
K8s environment	⚠️ Recommended to replace with Ingress + Service
Pure public network cloud environment	⚠️ Cloud provider LB is more hassle-free (e.g., AWS NLB)

VI. Description of the Practice Environment

The hands-on part of this blog series will be verified using the following home network environment:

Configuration item	value	Description
Network segment	192.168.0.0/24	Standard home LAN
DHCP scope	192.168.0.100 - 192.168.0.199	Router automatically assigns
Static IP range	192.168.0.200 - 192.168.0.254	For server use only
gateway	192.168.0.1	Router address

IP allocation for the three machines:

node	Role	Static IP
node1	Master Master	192.168.0.201
node2	Backup 1	192.168.0.202
node3	Backup 2	192.168.0.203
VIP	Virtual IP	192.168.0.200

💡 If your home network subnet is different (e.g.192.168.1.0/24), just take all 192.168.0.x Just replace it with your own network segment.

VII. Summary

Starting from the single point of failure issue in the direct-connect architecture, this paper gradually introduces Virtual IP the concept of, and evolved to VIP + Nginx multi-node of the high-availability ingress architecture.

The core idea of this plan is:

• Ingress high availability: VIP 192.168.0.200 Make the ingress IP “float,” with backend switching transparent to the product.

• Separation of duties: Nginx is responsible for proxying and health checks, while Master focuses on business.

• Product imperceptibility: The product always accesses the same VIP, without needing to be aware of backend changes.

In the next chapter, we will dive into the VRRP protocol and see how Keepalived makes the VIP truly “float.”

💡 This article is Part 1 of the "Distributed High-Availability Ingress Architecture in Practice Series"

• Click to view all articles

• Next article:VRRP Protocol and Keepalived: How Does a Virtual IP “Drift”?