A Node.js load balancer implementing consistent hashing, virtual nodes, active health checks, automatic failover, and reverse proxying.
The project was built to understand how distributed systems route requests across multiple servers while maintaining stable ownership of data.
- Consistent hashing for deterministic request routing
- Virtual nodes for improved load distribution
- Reverse proxying using HTTP
- Active health checks
- Automatic failover when a server becomes unavailable
- Automatic recovery when a failed server comes back online
- Support for GET, POST, PATCH, and DELETE requests
- Dynamic request routing based on a shard key
Traditional round-robin load balancing distributes requests evenly but does not preserve ownership of data.
This project instead uses consistent hashing to map keys to servers. The same key will consistently route to the same server, making it suitable for sharded systems such as caches, session stores, and distributed databases.
The goal was not to build a production-ready load balancer but to understand the underlying concepts used in distributed systems.
Client Request
↓
Load Balancer
↓
Consistent Hash Ring
↓
Owner Server Selection
↓
Reverse Proxy
↓
Backend Server
The load balancer never stores the data itself. Its responsibility is to determine which server owns a given key and forward the request accordingly.
Each physical server is assigned multiple virtual nodes on a hash ring.
Example:
server1#1
server1#2
server1#3
...
server2#1
server2#2
...
Keys are hashed onto the same ring.
Ownership is determined by moving clockwise until the first server node is encountered.
Benefits:
- Stable routing
- Minimal key movement when servers are added or removed
- Horizontal scalability
Without virtual nodes, distribution can become highly uneven because physical server hashes may cluster together.
This project uses 100 virtual nodes per physical server to improve balance.
Test: 10,000 keys
4 servers
100 virtual nodes per server
Results:
server1: 2909
server2: 2527
server3: 2283
server4: 2281
As the number of virtual nodes increases, the distribution approaches an even split.
The load balancer periodically checks server health using a dedicated /health endpoint.
Healthy status is stored in a hash map:
Server URL → Health Status
Example:
http://localhost:3001 → true
http://localhost:3002 → false
http://localhost:3003 → true
If a server becomes unavailable:
- Health checks mark the server as unhealthy.
- Requests that would normally route to that server are redirected clockwise around the ring.
- Traffic automatically returns when the server recovers.
Example:
Key → Server 1
↓
Server 1 crashes
↓
Key → Server 2
↓
Server 1 restarts
↓
Key → Server 1
The load balancer acts as a reverse proxy.
Incoming requests are routed to the appropriate backend server while preserving the original request method.
Supported methods:
- GET
- POST
- PATCH
- DELETE
load-balancer/
├── balancer.js
├── server1.js
├── server2.js
├── server3.js
└── README.md
Start the backend servers:
node server1.js
node server2.js
node server3.js
Start the load balancer:
node balancer.js
Access the load balancer:
Examples:
GET /user123
POST /user123
PATCH /user123
DELETE /user123
Request:
GET /user123
Key:
user123
↓
Hash:
MurmurHash(user123)
↓
Owner:
server2#43
↓
Physical Server:
server2
↓
Forward To:
- WebSocket support
- Dynamic node registration
- Request metrics and monitoring
- Replication between servers
- Gossip-based membership management
- Distributed consensus for cluster management
- TLS support
- Weighted virtual nodes
- Node.js
- Express
- MurmurHash3
- http-proxy-middleware
- Consistent hashing
- Sharding
- Virtual nodes
- Reverse proxying
- Active health checks
- Automatic failover
- Distributed system design fundamentals
This project was built as a learning exercise to understand how distributed systems route traffic and scale beyond a single server.