Load Balancing

# CHAPTER 6

Load Balancing #

1. Introduction #

2. Learning Objectives #

• Define the function and necessity of a Load Balancer in distributed systems.

• Explain common load balancing algorithms (Round Robin, Least Connections).

• Differentiate between a Load Balancer and a Reverse Proxy.

• Engineer "Health Checks" and automatic Failover architectures.

• Understand Layer 4 vs. Layer 7 load balancing.

3. What is a Load Balancer? #

• The Concept: When a user types www.example.com, their browser does not connect to your Web Server. It connects to the Load Balancer. The Load Balancer looks at the massive pool of available Web Servers, picks the one with the least amount of work, and secretly forwards the user's request to that specific server.

• The Magic: The user has no idea this is happening. They think they are talking to one giant computer.

4. Routing Algorithms #

• Round Robin: The simplest method. It just goes down the list sequentially. (Request 1 goes to Server A, Request 2 goes to Server B, Request 3 to Server C, Request 4 back to Server A).

• Least Connections: The load balancer monitors how many active connections each server currently has. It sends the next request to the server with the absolute lowest number of active connections. (Best for heavy, long-running requests).

• IP Hashing: It looks at the user's IP address, runs a math formula, and guarantees that the same user will *always* be routed to the exact same server. (Crucial if your architecture is incorrectly relying on "stateful" web servers).

5. Health Checks and Failover #

• Health Checks (The Pulse): Every 5 seconds, the Load Balancer sends a tiny "ping" request to all 100 Web Servers.

• The Failover: If Server #42 crashes and stops responding to the ping, the Load Balancer instantly marks Server #42 as "Dead." It immediately stops sending traffic to it. The users never see an error screen because their requests are instantly routed to the surviving 99 servers. This is the definition of High Availability.

6. Reverse Proxies (Security and SSL) #

• The Shield: A Reverse Proxy hides the internal IP addresses of your Web Servers. Hackers can only attack the Load Balancer, protecting your internal network.

• SSL Termination: Encrypting and decrypting HTTPS traffic is heavily CPU intensive. Instead of making your 100 Web Servers waste CPU power decrypting traffic, the Load Balancer handles all the SSL decryption at the front door ("SSL Termination") and passes raw, unencrypted HTTP traffic internally to your safe web servers.

7. Diagrams/Visual Suggestions #

                  [ Internet ]
                       |
               [ Load Balancer ] (Checks Health)
               /       |        \
             /         |          \
           /           |            \
[ Server A ]      [ Server B ]      [ Server C ]
  (Healthy)        (CRASHED)         (Healthy)
      ^                                  ^
      |                                  |
Traffic routed here                Traffic routed here

8. Best Practices #

• Redundant Load Balancers: You added a Load Balancer to prevent your web servers from being a Single Point of Failure (SPOF). But now, the Load Balancer itself is a SPOF! If it crashes, the whole site goes down. *Best Practice:* Always deploy Load Balancers in an Active-Passive pair. If the Primary Load Balancer dies, the Secondary one instantly takes over its IP address within milliseconds.

9. Common Mistakes #

• Layer 4 vs. Layer 7 Confusion:

• *Layer 4 (Transport):* Routes traffic based purely on IP addresses and ports. It is incredibly fast but blind to the data.

• *Layer 7 (Application):* Reads the actual HTTP payload. *The Mistake:* Using Layer 4 when you need intelligent routing. If you want requests for /video to go to a specialized Video Server, and /chat to go to a Chat Server, you MUST use a Layer 7 Load Balancer because it can read the URL path.

10. Mini Project: Nginx Reverse Proxy Setup #

1. 1. The Scenario: We have 3 web servers running a backend app.

1. 2. The Code (nginx.conf):

upstream my_backend {
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
    server 10.0.0.3:8080;
}

server {
    listen 80;
    location / {
        proxy_pass http://my_backend;
    }
}

1. 3. The Result: Nginx will automatically intercept all traffic on port 80 and distribute it evenly across the 3 internal servers using a default Round Robin algorithm.

11. Practice Exercises #

1. 1. Define the role of a Load Balancer in a horizontally scaled system. How does it enable "High Availability"?

1. 2. Explain the difference between the "Round Robin" and "Least Connections" routing algorithms. In what scenario would Round Robin fail to distribute load evenly?

12. MCQs with Answers #

13. Interview Questions #

• Q: You horizontally scale your architecture to 50 web servers, but you place a single Load Balancer in front of them. What architectural vulnerability have you just created, and how do you resolve it? (Hint: Active-Passive redundancy).

• Q: Explain the difference between a Layer 4 Load Balancer and a Layer 7 Load Balancer. Why might an API Gateway strictly require Layer 7 capabilities?

• Q: Your web architecture relies entirely on "Stateful" sessions stored in the local RAM of individual web servers. If you implement a standard Round Robin load balancer, what catastrophic UX failure will occur when a user clicks to a new page, and how does the "IP Hashing" algorithm patch this bad design?

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #