When the Load Balancer Becomes the Bottleneck
In a standard load balancing setup, all traffic flows symmetrically: Client → LB → Server → LB → Client. The LB handles both the small incoming request and the large outgoing response. For most web applications this is fine — an HTTP request is a few hundred bytes, and the response is a few kilobytes.
But consider video streaming. A client sends a GET /movie.mp4 request that is 200 bytes. The server responds with 4 gigabytes of video data. If all 4GB must pass through the LB, the LB's network interface becomes the bottleneck for your entire video delivery infrastructure. You would need to scale the LB's bandwidth linearly with your video traffic — an expensive and architecturally fragile approach.
Direct Server Return (DSR) — also called Direct Routing — solves this by making the return path asymmetric:
- Ingress: The client's request arrives at the LB's VIP.
- Forward (L2 manipulation): The LB forwards the packet to a backend server by changing the MAC address (Layer 2 address) in the Ethernet frame to the backend's MAC address, while leaving the Destination IP unchanged (still the VIP). This only works when the LB and backends are on the same Layer 2 network segment.
- Backend trick: The backend server must be configured with the VIP address on a loopback interface (e.g.,
lo:0) so it accepts packets addressed to the VIP. It processes the request normally. - Direct Egress: The backend server sends its response directly to the client's IP, bypassing the LB entirely. The source IP of the response is the VIP (from the loopback), so the client sees a coherent conversation with the VIP.
The result is a triangle: Client → LB → Server, and Server → Client directly. The LB only ever handles the small request packets. All the heavy response bandwidth flows directly from the server to the internet.
Where it's used: DSR is the architecture behind high-bandwidth content delivery — video streaming platforms, large file downloads, and any service where response data volume dwarfs request data volume. It is also used in Linux Virtual Server (LVS) deployments and some hardware load balancer configurations.
The constraint: DSR requires the LB and all backend servers to be on the same Layer 2 broadcast domain (the same VLAN or subnet). It cannot work across routed network boundaries, which limits its use in cloud environments where L2 adjacency is not guaranteed.
"How does YouTube serve video at scale without the load balancer becoming a bottleneck?" is a real SRE interview question. The answer involves DSR (or its cloud equivalent — direct routing from CDN edge nodes to clients). The key insight to articulate is the asymmetry of web traffic: requests are tiny, responses are large. Any architecture that routes both directions through a central chokepoint will eventually be limited by that chokepoint's bandwidth, not by the capacity of the backend servers.