How Meta turned the Linux Kernel into a planet-scale Load Balancer. Part I

A deep architectural narrative on XDP, eBPF, stateless routing, and why hyperscale traffic outgrew proxies.

The Night Load Balancers stopped feeling like plumbing

The first time I saw a production system degrade because of its load balancer, nothing spectacular happened.

No outages.
No alarms.
No crashes.

Latency just started creeping upward, first p95, then p99, until everything felt sticky. Requests weren’t failing. They were waiting. Queues lengthened. Retries multiplied. Backends looked saturated despite idle CPUs.

What should have been a minor networking blip slowly metastasized into systemic instability.

The system wasn’t compute-bound.
It wasn’t storage-bound.
It wasn’t even network-bandwidth-bound.

It was packet-movement-bound.

At the time, that realization felt wrong. Load balancers were supposed to be solved infrastructure, plumbing you deploy once and forget. You scale them horizontally, tune some buffers, maybe add another tier, and move on.

That night changed how I thought about them. I realized that load balancing isn’t plumbing at all.

It’s distributed systems engineering hiding inside the network layer.

Years later, when I first read about Facebook’s Katran, that same dissonance came rushing back, not because Katran was fast (many systems are fast), but because it treated the problem so differently from everything else I’d seen.

It didn’t try to be a better proxy. It didn’t try to optimize user-space networking. It didn’t try to understand protocols, sessions, or requests.

It tried to disappear.

Katran’s ambition was not to sit in front of traffic, but to move packets before the operating system itself even noticed they existed. Not as an optimization, but as a redefinition of what load balancing actually is.

This piece is an attempt to unpack that redefinition, not as a feature tour, but as a system story:

1. how Meta ended up building a kernel-level, stateless, line-rate load balancer;

2. why proxies stopped scaling; how eBPF and XDP turned Linux into a programmable switch;

3. and what this architecture tells us about where infrastructure is heading.

---

When proxies became the bottleneck

At small scale, load balancers feel like coordination infrastructure.

They terminate TLS, parse HTTP, enforce policies, retry requests, expose metrics, and act as programmable gateways between clients and services.

At medium scale, they become throughput machines. You start tuning epoll loops, socket buffers, thread pools, kernel parameters, memory allocators. But everything still feels tractable.

At hyperscale, Meta scale, something breaks conceptually.

Traffic no longer looks like “clients making requests.”
It looks like “millions of packets per second, continuously, forever.”

In that regime, the bottleneck stops being computation and becomes movement. The system isn’t struggling to compute responses. It’s struggling to move bytes through layers of software fast enough.

A traditional proxy pipeline looks roughly like this:

NIC → kernel networking stack → socket buffers
    → user-space context switch → protocol parsing
    → routing decision → connection pool lookup
    → buffering → write syscall → kernel → NIC

Every arrow carries some real costs:

• Cache misses.

• Branch mispredictions.

• Memory allocation and deallocation.

• Kernel ↔ user context switches.

• Lock contention.

• Scheduling delays.

• Buffer copies.

• Queue management overhead.

At tens of thousands of requests per second, this is noise. At millions of packets per second, this is overhead, but at tens of millions, this becomes physics.

At Meta scale, the load balancer fleet itself grew into one of the company’s largest compute clusters: not because it was doing intellectually difficult work, but because it was burning enormous CPU cycles just forwarding bytes.

Worse, that cost surfaced primarily as tail latency, the kind that cascades invisibly through distributed systems. Slight delays trigger retries. Retries amplify load. Load amplifies queueing. Queueing amplifies latency variance.

What starts as packet-processing overhead becomes application-level instability.

This is where the framing changed.

Meta engineers stopped asking:

How do we build a faster proxy?

And instead started asking:

Why are we proxying at all?

---

The conceptual break

Katran begins with a deceptively simple idea:

Load balancing is not about requests.
It’s about packets.

This sounds trivial until you follow it all the way down.

Most systems reason about traffic at the so-called Layer 7. We think in terms of HTTP verbs, paths, cookies, headers, auth tokens, retries, sessions, and request lifecycles. Load balancers become policy engines and application routers.

But stripped to fundamentals, routing is just:

A packet arrives.
It must be forwarded somewhere else.

That decision does not require:

• Parsing payloads.

• Understanding protocols.

• Tracking sessions.

• Maintaining connection state.

• Allocating memory.

• Buffering streams.

It requires in fact:

• Reading a few header fields.

• Mapping them deterministically to a backend.

• Rewriting destination addresses.

Once that’s accepted, the rest of Katran’s architecture follows almost inevitably.

Once you accept that routing doesn’t require user space, a strange realization follows. Why enter user space at all?

If routing doesn’t require sockets, why traverse the TCP stack?
If it doesn’t require state, why store state?
If it doesn’t require buffering, why buffer?

Most traditional networking pipelines do all of these things: not because routing needs them, but because the systems we built around routing do.

Over time, layers accreted: sockets, connection tracking, session tables, queues, retries, buffers. Routing became entangled with everything else, until forwarding a packet meant walking through half the operating system.

Katran asks a very much simpler question.

If routing is just computation, like a deterministic function of packet headers, then why not perform that computation at the earliest possible moment, the instant the packet enters the machine, and then get out of the way?

That’s exactly what Katran does.

It runs in the kernel datapath, before the TCP stack, before sockets, before user space, before state is allocated, before buffers pile up.

A packet arrives. Its tuple is hashed. A backend is chosen. The destination is rewritten. The packet moves on.

No sessions. No tables. No queues. Not even memory.

Just math, applied at line rate, and that’s because Katran doesn’t optimize routing.

It eliminates everything routing never needed in the first place.

---

The physics of Packet Movement

Before diving deeper, it’s worth stepping back and looking at the constraint Katran is truly built to respect: physics.

At hyperscale, performance isn’t just a matter of elegant algorithms or clever data structures. It’s about the raw realities of moving bits through silicon.

Every design choice carries a cost in CPU cycles, memory bandwidth, and latency. At this scale, even small inefficiencies multiply into catastrophic slowdowns.

Every packet copied between kernel and user space consumes memory bandwidth. Every crossing of privilege boundaries introduces pipeline stalls.

Every memory allocation risks cache thrash or fragmentation. Every context switch adds jitter. Every queue introduces contention, every interrupt triggers scheduling overhead.

NUMA topology, DMA latency, cache line locality, branch predictability; all of it suddenly matters, not in theory, but in the measured tail latencies of millions of concurrent flows.

Traditional proxies accumulate these costs by design. They are built to understand packets: to parse headers, terminate TLS, enforce policies, track sessions.

Each feature is useful at a semantic level, but each comes at a physical price. And at planetary scale, that price dominates everything else.

Katran takes the opposite approach. It doesn’t want to know what the packet means. It doesn’t parse HTTP, it doesn’t validate TLS, it doesn’t track sessions. All it cares about is where the packet should go. That singular focus allows it to escape the usual costs.

By moving routing decisions to the earliest possible point, the kernel’s first receive path, before the networking stack even wakes up, Katran eliminates most of the overhead proxies can’t avoid.

The packet hits the NIC, the tuple is hashed, a backend is chosen, the destination is rewritten, and the packet continues. No user-space copies. No socket buffers. No queues. No connection tables. Almost no memory traffic beyond the computation itself.

In other words, Katran doesn’t just optimize for speed: it co-locates computation with the physics of the system, letting the network move at line rate while avoiding the hidden costs that would crush any traditional proxy at hyperscale.

---

XDP and eBPF

None of this would have been remotely feasible a decade ago.

Kernel-level packet processing used to be the domain of fear and ritual. You wrote kernel modules in C, recompiled kernels, rebooted machines, and prayed nothing would panic.

Debugging meant sprinkling printks throughout the code and hoping the kernel didn’t crash before you could see the output.

It was brittle, slow, and incompatible with the dynamic, constantly changing demands of modern production infrastructure.

Then came eBPF, the extended Berkeley Packet Filter, and XDP, the eXpress Data Path. Together, they changed the rules of the game.

eBPF introduced something unprecedented: safe, sandboxed programs that could run directly inside the kernel.

You could load them dynamically, update them on the fly, and remove them at runtime: all without touching the kernel’s core or risking catastrophic panics.

The verifier guaranteed bounded execution, prevented unsafe memory access, and ensured termination. Suddenly, the kernel became programmable, but without the traditional risks that had made kernel development a high-stakes gamble.

XDP tied this capability to the earliest possible packet hook, right after the NIC’s DMA copied the packet into memory, long before the kernel networking stack woke up, before socket buffers were allocated, before protocol parsing began.

At that instant, the packet is nothing more than bytes in memory. And at that instant, you get to run code on it.

This is the environment where Katran lives. It’s not a load balancer in the traditional sense. It’s a programmable L3/L4 forwarding pipeline, implemented in software but operating at the same layer as a hardware switch.

It doesn’t parse requests, terminate TLS, or track sessions. It doesn’t worry about retries, circuits, or headers.

It computes packet destinations at line rate and moves on. Everything else (proxies, policies, application logic) happens after the packet has already been routed correctly and efficiently.

From this perspective, Katran isn’t an optimization. It’s a reframing.

By combining eBPF and XDP, Katran elevates routing to the earliest stage possible, removes the overhead traditional systems carry, and brings software routing into the same performance envelope as hardware switches; all without sacrificing the flexibility, safety, or dynamism that modern production environments demand.

---

The Katran Data Plane

Let’s follow a single SYN packet entering a Katran node, step by step, to see exactly what makes this system so different.

Picture it in your mind: every nanosecond counts, every memory access is a potential bottleneck, and every decision must be deterministic.

The packet arrives at the NIC. The network card’s DMA engine deposits it into memory. The kernel is still asleep for the most part, unaware of what just arrived. At this moment, the XDP hook fires, and Katran’s eBPF program takes control.

From here, the packet’s journey is unlike anything a traditional stack would do. Katran doesn’t allocate memory. It doesn’t touch sockets. It doesn’t consult a connection table.

It doesn’t parse HTTP headers or check TLS states. It doesn’t wait for user-space processes to schedule it. It doesn’t buffer or queue.

All it does is look at a few bytes of the header: the classic 5-tuple that uniquely identifies the flow.

struct iphdr *ip = data + ETH_HLEN;
struct tcphdr *tcp = data + ETH_HLEN + sizeof(*ip);

__u32 src_ip = ip->saddr;
__u32 dst_ip = ip->daddr;
__u16 src_port = tcp->source;
__u16 dst_port = tcp->dest;
__u8 proto = ip->protocol;

Those five fields, like source IP, destination IP, source port, destination port, and protocol, become the entire input to Katran’s routing decision. Nothing else matters.

Next comes the whole heart of the computation: hashing and consistent mapping to a backend.

Katran uses the 5-tuple to produce a deterministic key, which indexes directly into a consistent hashing ring stored in an eBPF map.

__u64 key = hash_5tuple(src_ip, dst_ip, src_port, dst_port, proto);
__u32 backend_idx = bpf_map_lookup_elem(&backend_ring, &key);

That index points to another map that contains backend IP addresses and ports:

struct backend backend = backends[backend_idx];

Katran then rewrites the packet headers in place:

ip->daddr = backend.ip;
tcp->dest = backend.port;

Checksums are recomputed using kernel helpers, which are optimized for in-place, zero-copy updates.

And then, this is the magical moment, the packet is sent immediately:

return XDP_TX;

No socket buffers.
No TCP stack.
No connection tables.
No memory allocations.
No context switches.
No scheduling delays.

Just:

Packet arrives → compute backend → rewrite headers → transmit

From the backend’s perspective, the packet looks like it came directly from the client. From the client’s perspective, it came from the VIP. From the kernel’s perspective… the packet essentially never existed outside this tiny, deterministic computation.

The routing decision executes in a fixed, predictable number of instructions. It takes microseconds. There is no jitter from GC pauses, no locks to contend over, no queues to saturate.

The system scales linearly with CPU cores, not with the number of flows or the size of the connection table.

But the performance, impressive as it is, is only part of the story. The deeper shift is architectural: the network stops tracking state. There is no per-flow memory, no NAT tables, no sticky sessions. Routing becomes a pure function:

flow tuple → hash → backend → forward

Everything else (failure recovery, backend updates and scaling) can be handled by updating the small, shared hash ring.

There is no explosion of per-flow state, no coordination across nodes, and no warm-up after failures.

In other words, Katran achieves hyperscale not by faster processors, or clever batching, or hardware acceleration, although it uses those wisely, but by eliminating everything routing doesn’t actually need.

It’s a profound simplification. And once you internalize it, you begin to see why Katran doesn’t just move packets faster: it reshapes the way we think about packet routing entirely.

---

Routing as pure computation

Traditional load balancers remember things.

They remember which backend a connection was assigned to, which NAT mapping applies to a flow, which sessions are active, which backends are draining, which retries are still in flight.

Every packet doesn’t just pass through the system: it leaves a trace. A new entry in a table. A new piece of memory that must be managed, synchronized, persisted, migrated, invalidated, and eventually garbage-collected.

At small scale, this feels manageable. At large scale, it becomes suffocating.

State grows with traffic. Traffic grows with success. And in distributed systems, state is not just complexity: it is fragility.

It must survive failures. It must remain consistent across replicas. It must be reconstructed after crashes. Over time, the system stops being a load balancer and becomes a distributed state machine that happens to forward packets.

Katran refuses this entire model. Instead of remembering:

“Flow A maps to backend X.”

Katran recomputes:

“Given tuple A, backend X is the correct destination.”

Every time. From scratch. Deterministically.

Same input → same output.

No memory. No eviction. No synchronization. No garbage collection.
No coordination.

Routing stops being a mutable process and becomes a pure function.

This is not a performance trick; it is a philosophical shift. Once routing is expressed as computation rather than storage, failure semantics collapse into simplicity.

A node can restart and instantly resume forwarding traffic, because nothing was ever stored. Scaling no longer requires migrating flow tables.

Draining no longer requires tracking sessions. There is no warm-up, no replay, no reconstruction; only recomputation.

This is where consistent hashing becomes central.

Instead of tracking where flows went, Katran hashes the flow tuple and maps it deterministically onto a backend via a hash ring. Every packet independently computes its destination. Every node running Katran executes the same function.

As long as they share the same configuration, they produce the same routing decisions: without coordination, without memory, without state.

Routing becomes mathematics.

Not “remember what happened”, but “recompute what must happen”.

And that single shift, from stored decisions to deterministic computation, is the architectural heart of Katran.

---

Epilogue

Katran isn’t just a faster load balancer. It’s a redefinition of what load balancing means at scale.

Traditional systems treat routing as storage: track flows, maintain tables, buffer packets, reconcile state. At small scale, it works.

At Meta scale, it collapses under its own complexity. Latency creeps up. Queues grow. Retries multiply. The plumbing leaks, invisibly, into application performance.

Katran treats routing as pure computation. A packet arrives, a hash is computed, a backend is chosen, the headers are rewritten, and the packet moves on. No state. No coordination. No memory overhead. No jitter.

The network itself becomes stateless, deterministic, and trivially scalable. Failure recovery, draining, scaling; all of it reduces to updating a simple hash ring. The system doesn’t need to remember. It only needs to compute.

By moving routing into the kernel’s earliest receive path and stripping away everything that isn’t essential, Katran co-locates computation with the physics of packet movement.

It eliminates the overhead proxies carry by design, brings software routing close to hardware performance, and reshapes the architectural landscape for planetary-scale infrastructure.

In the end, Katran is less about “doing load balancing faster” and more about rethinking what load balancing is.

It’s a system that vanishes in the network, leaving only mathematics and determinism behind; a quiet revolution in how packets flow through the world’s largest data centers.

At hyperscale, that subtle shift doesn’t just improve performance. It restores simplicity, reliability, and sanity to a layer of the network that, for too long, had been treated as plumbing when it was always a distributed system.

Katran reminds us that sometimes, the best way to handle complexity isn’t to manage it: it’s to eliminate it entirely.