What Is Load Balancing?
Load balancing is the process of distributing incoming network or application traffic across multiple backend servers.
Instead of sending every request to one machine:
Users → Application Server
traffic first reaches a load balancer:
┌→ Server 1
Users → Load Balancer ─→ Server 2
└→ Server 3
↓
Shared Database
The load balancer selects an eligible backend according to a routing algorithm and server availability.
The result can be better scalability, resource utilization and availability—as long as the rest of the architecture is also designed correctly.
Why Do Applications Need Load Balancing?
Imagine an online food-ordering project running on one Node.js server.
With 10 users, the application may work smoothly. With 1,000 concurrent users, that same server may need to process authentication, searches, carts, payments, database queries and API calls simultaneously.
Vertical scaling gives the same server more resources.
Horizontal scaling adds more application instances.
Vertical scaling: One server → More CPU/RAM
Horizontal scaling: One server → Server A + Server B + Server C
Load balancing is the traffic-distribution layer that makes horizontal scaling practical.
How Does a Load Balancer Work?
Suppose three application instances are available.
A user requests:
GET /api/products
The load balancer:
- receives the request;
- identifies eligible backend servers;
- applies its routing algorithm;
- forwards the request;
- returns or relays the response; and
- continues distributing new traffic.
The set of application servers is commonly called a backend pool, server pool, target group, or—in NGINX terminology—an upstream group.
Types of Load Balancing
Layer 4 Load Balancing
Layer 4 operates at the transport layer.
Routing decisions primarily use information such as:
- source and destination IP;
- TCP or UDP;
- ports; and
- connections.
It does not need to inspect an HTTP URL such as /api/orders.
Layer 7 Load Balancing
Layer 7 understands application protocols such as HTTP and HTTPS.
It can route using information such as:
/api/* → API servers
/images/* → media servers
/admin/* → admin application
That makes Layer 7 especially useful for websites, REST APIs and microservices.
|
Feature |
Layer 4 |
Layer 7 |
|
Uses IP/port information |
Yes |
Yes |
|
Understands HTTP paths |
No |
Yes |
|
Header/cookie routing |
No |
Yes |
|
Content-aware routing |
No |
Yes |
|
Typical use |
Network/TCP traffic |
Web/API traffic |
Load balancers can also be implemented as hardware appliances, software such as NGINX or HAProxy, or managed cloud services. Cloud platforms further distinguish concepts such as internal vs external and regional vs global load balancing.
Static vs Dynamic Load Balancing
Another useful classification concerns how the routing decision is made.
|
Static Algorithms |
Dynamic Algorithms |
|
Follow predefined rules |
Consider current system state |
|
Lower decision complexity |
More adaptive |
|
Round Robin is a common example |
Least Connections is a common example |
|
Less workload awareness |
Better for uneven workloads |
Neither category is automatically better. The workload should determine the algorithm.
Major Load Balancing Algorithms
1. Round Robin
Requests are distributed sequentially:
Request 1 → A
Request 2 → B
Request 3 → C
Request 4 → A
NGINX uses Round Robin by default when no alternative method is configured.
Best for: servers with similar capacity and reasonably similar request cost.
2. Least Connections
The next request goes to the server with fewer active connections.
|
Server |
Active Connections |
|
A |
14 |
|
B |
5 |
|
C |
9 |
Server B becomes the likely choice.
This can work better when connections have different durations.
3. Weighted Routing
Suppose Servers A and B have 8 GB RAM while Server C has more capacity.
A greater weight can be assigned to C so it receives proportionally more traffic.
4. IP Hash
A hash based on the client IP helps consistently route a client toward the same backend.
This can provide session affinity, although shared or stateless session architecture is generally more scalable.
Other Algorithms You May Encounter
Production systems may also use:
- weighted least connections;
- least response time;
- random selection; and
- consistent hashing.
The important question is not, “Which algorithm is famous?” It is, “Which signal best represents load in my application?”
How to Choose a Load Balancing Algorithm
Use this simplified decision framework:
|
Situation |
Starting Choice |
|
Similar servers and request cost |
Round Robin |
|
Requests have very different duration |
Least Connections |
|
Servers have unequal capacity |
Weighted method |
|
Client affinity genuinely required |
Hash/sticky routing |
|
Response speed varies significantly |
Response-time-aware method |
Always validate the choice through testing.
Health Checks and Failover
A load balancer should avoid an unavailable backend.
Server A → Healthy
Server B → Failed
Server C → Healthy
New traffic should normally be sent to A and C.
There is an important NGINX distinction here.
NGINX Open Source performs passive health checks. It observes failures that occur while forwarding real requests and can temporarily stop selecting an upstream server using settings such as max_fails and fail_timeout.
NGINX Plus additionally supports active health checks, where the load balancer periodically sends dedicated probe requests.
Therefore, creating /health in your Node.js application does not mean the basic NGINX Open Source configuration automatically polls that endpoint.
Session Persistence vs Stateless Applications
Load balancing creates a common session problem.
Suppose Server A stores a logged-in user's session only in local memory.
The next request reaches Server B.
Server B does not know that session.
Better approaches include:
- Redis-backed sessions;
- database-backed sessions;
- appropriately designed tokens; or
- sticky sessions only when genuinely required.
For horizontal scaling, keep application instances as stateless as practical so any healthy instance can serve the request.
Reverse Proxy vs Load Balancer
These concepts overlap but are not identical.
A reverse proxy receives client requests on behalf of backend applications and can provide routing, TLS handling, caching, header manipulation and other edge features.
A load balancer specifically focuses on distributing traffic across multiple eligible backends.
NGINX can perform both roles.
TLS Termination, Autoscaling and High Availability
A Layer 7 load balancer may terminate HTTPS/TLS at the traffic layer and then communicate with backend services according to the chosen security architecture.
Load balancing should also not be confused with autoscaling:
Load balancing: decides where traffic goes.
Autoscaling: changes how many application instances exist.
They are often used together.
Finally, placing three backend servers behind one NGINX instance does not automatically create complete high availability. If that single NGINX server fails, it can become a single point of failure.
Production systems therefore make the load-balancing tier redundant using managed services, multiple load-balancer instances, DNS/failover mechanisms or equivalent designs.
Step-by-Step NGINX Load Balancing Example
Assume two Node.js applications run on:
127.0.0.1:3001
127.0.0.1:3002
Step 1: Create the upstream pool
upstream student_app {
server 127.0.0.1:3001 max_fails=3 fail_timeout=30s;
server 127.0.0.1:3002 max_fails=3 fail_timeout=30s;
}
Step 2: Forward requests
server {
listen 80;
location / {
proxy_pass http://student_app;
}
}
No explicit method is configured, so NGINX uses Round Robin.
Step 3: Validate and reload
sudo nginx -t
sudo nginx -s reload
Make Server 1 return:
Hello from Server 1
and Server 2:
Hello from Server 2
Then send repeated requests and observe the responding instance.
Step 4: Test failure
Stop one backend and repeat the test.
Record:
- successful requests;
- failed requests;
- response times;
- backend selected; and
- recovery behaviour.
Turn the Demo Into Real Experimental Evidence
Do not write that your architecture “improved performance” unless you measured it.
Use k6, wrk, ApacheBench or another load-testing tool and record:
|
Setup |
Requests/sec |
p95 Latency |
Error Rate |
Notes |
|
One Node.js instance |
Measure |
Measure |
Measure |
Baseline |
|
Two instances + NGINX |
Measure |
Measure |
Measure |
Compare |
|
One backend stopped |
Measure |
Measure |
Measure |
Failover test |
Also document:
- CPU and RAM;
- Node.js version;
- NGINX version;
- concurrency;
- request count;
- tested endpoint; and
- test-machine configuration.
Those details turn a generic architecture diagram into reproducible engineering evidence.
Using Load Balancing in a Final-Year Project
An e-commerce, ERP, booking, healthcare, food-ordering or campus application can use:
┌→ App Instance 1
Users → NGINX LB ─┼→ App Instance 2 → Shared Database
└→ App Instance 3
Your project report can document:
- scalability requirement;
- horizontal scaling;
- architecture diagram;
- balancing algorithm;
- session strategy;
- passive health handling;
- failure experiment;
- load-test results;
- limitations; and
- future deployment architecture.
During a viva, explain why you selected the algorithm rather than simply saying, “We used NGINX.”
Common Load Balancing Mistakes
Avoid:
- adding servers before fixing slow SQL or inefficient APIs;
- storing critical sessions only in local memory;
- assuming Round Robin means equal CPU usage;
- forgetting that the load balancer itself can fail;
- ignoring database bottlenecks;
- confusing autoscaling with load balancing; and
- claiming performance improvement without measurements.
Frequently Asked Questions
What is load balancing in simple words?
Load balancing distributes incoming traffic across multiple backend servers instead of sending every request to one server.
What are the main types of load balancing?
Common classifications include Layer 4 and Layer 7 load balancing, as well as hardware, software and managed cloud load balancers.
Which load balancing algorithm is best?
There is no universal best algorithm. Round Robin is simple for similar servers, while Least Connections, weighted methods or hash-based routing may suit different workloads.
What is Layer 4 vs Layer 7 load balancing?
Layer 4 uses transport information such as IP addresses, ports and TCP/UDP. Layer 7 understands application-level information such as HTTP paths, headers and cookies.
Is NGINX a load balancer or reverse proxy?
NGINX can operate as both a reverse proxy and a load balancer.
Does NGINX Open Source perform active health checks?
NGINX Open Source provides passive upstream health checks based on real request failures. Periodic active health checks are available with NGINX Plus.
What is load balancing vs autoscaling?
Load balancing distributes requests among available instances. Autoscaling increases or decreases the number of instances according to demand or configured rules.
Is load balancing useful for a final-year project?
Yes. It can demonstrate horizontal scalability, availability, system design, backend architecture, performance testing and failure handling in a measurable way.
Conclusion
Load balancing is what turns multiple application instances into a usable scalable service.
A load balancer receives traffic and distributes it among backend servers using strategies such as Round Robin, Least Connections, weighted routing or hashing. Layer 4 operates primarily with transport-level information, while Layer 7 can make application-aware decisions.
For a final-year project, keep the experiment realistic.
Run two Node.js instances. Put NGINX in front of them. Keep shared state outside individual servers. Test repeated requests. Stop one backend. Measure throughput, p95 latency and errors.
Then document what happened.
That provides something stronger than another theoretical definition: an architecture you can implement, test, defend and improve.
The revised article deliberately avoids fabricated benchmark numbers while giving you the structure required to add first-hand evidence later.
