Product / high-performance L4
XLB significantly lowers the operating cost and maintenance overhead of extreme-scale load balancing. Handle millions of requests per second with fewer servers, no traffic-based cloud pricing, and no proxy tuning.
Why XLB moves more traffic per server
HAProxy and NGINX terminate the client connection, pass application data through a proxy process, and establish a second connection to the backend. XLB keeps packet processing in the kernel and forwards the original payload without userspace copies, delivering lower latency and more consistent performance under load.
The load balancer owns and maintains two bidirectional sockets. Application data is copied into userspace and back to the kernel in both directions.
The client and backend keep one end-to-end connection. XLB routes each packet without reading, buffering, or copying the application payload, reducing latency and jitter on the load-balancer path.
Packet lifecycle
XDP runs early in the Linux receive path. XLB uses that position to handle the load-balancing work before a general-purpose application proxy would see the packet.
Match inbound IPv4/TCP traffic to a configured listener and port mapping. Traffic outside the configuration passes normally.
Look up an existing flow or assign a backend for a new connection from the currently available backend set.
Update the network and transport headers for the selected backend and maintain the paired flow state for return traffic.
Send the packet toward the backend. The application receives the original TCP flow directly.
Local management
A local XLB process reads the config, follows Kubernetes backend changes, and exports metrics. There is no cluster-wide VIP service, BGP manager, configuration database, or controller for your team to operate.
Configuration
Define the listener, one to eight port mappings, backend source, flow cleanup policy, shutdown window, and optional metrics exporter. That’s the contract.
Configuration referencename: openrtb-ingress
listen: auto
proto: tcp
mode: nat
ports:
- local_port: 443
remote_port: 8443
provider:
static:
backends:
- name: bidder-01
ip: 10.0.1.11
- name: bidder-02
ip: 10.0.1.12
otel:
enabled: true
endpoint: http://otel:4317
protocol: grpcOperational model
XLB uses ordinary Linux and Kubernetes primitives, keeps backends current automatically, and is completely tuning free with no separate control plane.
Run as a binary or privileged host-network container on an XDP-capable interface.
Use explicit IPs or continuously reconcile eligible Pods from a Kubernetes Service selector.
Use built-in metrics with the local status interface or ready-to-import Grafana and Datadog packages.
Explore monitoringKeep XDP attached briefly on shutdown and reset matching TCP traffic that arrives during the configured window.
Prefer native-driver mode for performance, with generic/SKB XDP as a compatibility fallback.
No worker, thread, buffer, socket, or connection-profile tuning. Configure the backends and run it.
Before you evaluate
Bring your traffic profile
We’ll help frame an evaluation around your NICs, packet sizes, connection churn, and application deadline.