> For the complete documentation index, see [llms.txt](https://jins-organization-2.gitbook.io/muse-on-engineering/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jins-organization-2.gitbook.io/muse-on-engineering/engineering/distributed-computing/differences-between-service-discovery-and-load-balancing/load-balancer.md).

# Load balancer

L4 load balancer works on connections; L7 load balancer works on requests; Client load balancer is more flexible but it needs to handle the complexity of making distributed load balancing decisions.

### **L4 Load Balancer (Transport Layer Load Balancer) - AWS NLB**

\
An L4 load balancer operates at the transport layer (Layer 4) of the OSI model. It balances client traffic based on transport layer information such as the source and destination IP addresses and ports.

When a client initiates a TCP connection, the L4 load balancer selects a backend server based on its load balancing algorithm (like Round Robin, Least Connections, etc.) and establishes a TCP connection with it. The load balancer then forwards packets from the client to the selected backend server without inspecting the content of the packets.

The load balancer maintains a table to track the client's IP and port with the corresponding backend server's IP and port. This allows the load balancer to route future packets in the same TCP connection to the same backend server, enabling connection persistence.

Common pitfalls of L4 load balancing include the inability to make routing decisions based on application-level data (like HTTP headers or cookies), and the potential for uneven load distribution if the load balancer's algorithm doesn't account for the actual load on the backend servers.

![](https://3853613271-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNfMOMQsrcNT8Waw8yWg4%2Fuploads%2FZPYsuKMnwluZIruEkrF7%2F0.png?alt=media)

### **L7 Load Balancer (Application Layer Load Balancer) - AWS ALB**

\
An L7 load balancer operates at the application layer (Layer 7) of the OSI model. It can inspect the content of the client's request and make routing decisions based on it. This allows for more sophisticated load balancing strategies, such as routing based on HTTP headers, cookies, or the URL path.

When a client initiates a TCP connection, the L7 load balancer establishes a TCP connection with the client. It then waits for the client to send an HTTP request. Once the load balancer receives the request, it selects a backend server based on its load balancing algorithm and the content of the request. It then establishes a separate TCP connection with the backend server and forwards the client's request.

Because the L7 load balancer maintains separate TCP connections with the client and the backend server, it can route different requests from the same client TCP connection to different backend servers. This allows for session persistence based on cookies or other application-level data.

Common pitfalls of L7 load balancing include increased latency due to the overhead of inspecting each request and maintaining separate TCP connections, and the potential for resource exhaustion if the load balancer has to maintain a large number of TCP connections.

![](https://3853613271-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNfMOMQsrcNT8Waw8yWg4%2Fuploads%2Fk2oMiWSL2vZLzoA3DAb9%2F1.png?alt=media)

### **DNS-based Load Balancer - AWS Route53/CloudMap**

\
A DNS-based load balancer uses the Domain Name System (DNS) to distribute client requests across multiple backend servers. When a client makes a DNS query for the load balancer's domain name, the load balancer responds with the IP address of one of the backend servers. The client then establishes a TCP connection directly with the backend server.

The load balancer can use various strategies to select a backend server, such as Round Robin, geographic location of the client, or the load on the backend servers. However, once the load balancer has responded to the DNS query, it has no control over the client's TCP connection with the backend server.

Common pitfalls of DNS-based load balancing include the inability to perform session persistence (since the load balancer is not involved in the TCP connection), and the potential for uneven load distribution due to DNS caching (since clients may continue to use a cached IP address even if the load balancer would have selected a different backend server).

![](https://3853613271-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNfMOMQsrcNT8Waw8yWg4%2Fuploads%2F4GocRpfys5De2aDBXwlD%2F2.png?alt=media)

### Client side load balancing

{% embed url="<https://netflixtechblog.com/netflix-edge-load-balancing-695308b5548c>" %}
d
{% endembed %}

{% embed url="<https://www.nginx.com/blog/nginx-power-of-two-choices-load-balancing-algorithm/>" %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://jins-organization-2.gitbook.io/muse-on-engineering/engineering/distributed-computing/differences-between-service-discovery-and-load-balancing/load-balancer.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
