Google's Maglev (NSDI 2016) is a software-based load balancer that processes 1 Gbps per core with a connection lookup table that uses consistent hashing. Unlike hardware LBs that rely on TCAM-based flow tables limited to a few hundred thousand entries, Maglev uses a Consistent Hash Table (CHT) that maps the 5-tuple of each connection to one of the backend servers. The CHT is a lookup table of size $M = 65537$ (a prime number), where each entry points to one backend. When a backend is added or removed, the CHT is recomputed and the affected entries (approximately $M/N$ for $N$ backends) are updated:

The key performance metric is Connection Tracking Rate: a server receiving 10 Mpps with 100+ byte packets must classify and forward each packet in under 100 ns. Maglev achieves this by (1) hashing the 5-tuple using a CRC32c hardware instruction (12 ns), (2) looking up the CHT entry via array indexing (3 ns), and (3) forwarding the packet to the backend's virtual MAC address via a pre-populated neighbor table. The total per-packet processing cost is 50-80 ns, well under the 100 ns budget. The CHT must be updated within 10 ms of a backend failure to prevent new connections from being assigned to the dead backend. Maglev uses a Rendezvous Hash mechanism where each connection is first hashed to a virtual "rendezvous point" in the CHT, and the two nearest backends clockwise from the point are selected. This provides Affinity for Consistent Hashing: existing connections to the surviving backend remain uninterrupted, while only the connections previously assigned to the failed backend are redirected to the new second-choice backend, minimizing the disruption to live traffic.

Direct Server Return (DSR), also known as Triangular Routing, eliminates the load balancer as a bottleneck for return traffic. In the standard proxy model, the client sends a request to the VIP, the load balancer rewrites the destination MAC to the backend server's MAC, the backend processes the request, and the response must flow back through the load balancer (which then rewrites the source IP back to the VIP). This creates a bottleneck: the LB must process both inbound and outbound traffic, doubling its throughput requirement. In DSR, the backend server sends the response directly to the client, bypassing the LB entirely. The path is asymmetric: request goes LB → server, response goes server → client:

This halves the LB throughput requirement—a 100 Gbps LB can terminate 100 Gbps of connections instead of 50 Gbps. The implementation requires that the backend server configures a loopback interface with the VIP address (for the client to see the correct source IP on the response) and enables reverse path filtering to accept the response's source MAC from the directly connected router rather than the LB. In Linux, this is done by setting $rp_filter = 2$ (loose mode) and adding the VIP to the loopback interface. DSR is the standard configuration for L4 LBs in 2026 (AWS NLB, Google's Maglev, Azure ILB) because it halves the hardware cost and eliminates the LB as a latency bottleneck for response data. The trade-off is that DSR cannot perform Connection Draining: if a backend fails, in-flight response packets are lost because the LB cannot buffer the TCP stream. The application must handle retransmission at the client side or use a dual-LB configuration where a secondary LB monitors for server failure and injects RST packets on behalf of the failed server.