Load balancing has moved beyond round-robin
For three decades, load balancing has been the workhorse that keeps origin servers healthy and users connected. The core idea hasn't changed: steer traffic away from failing origins and, in more capable systems, distribute load according to a chosen algorithm. What has changed is the scale and shape of modern applications. A fixed set of servers in a single data center no longer matches how users reach the internet, and a one-size-fits-all balancing strategy fails businesses that have different architectures and different objectives.
The features that matter now are ease of use, fast propagation of changes, and above all, flexibility. Different businesses succeed in different ways and face different technical constraints. Consider a few common scenarios:
- An application decomposed into microservices, where each origin supports a specific segment of the app. Traffic must be routed by path so that no single origin is overwhelmed and each request lands on the correct server.
- A request header carrying a value such as
PS5that should direct traffic to the data center matching that header. - A split-horizon DNS architecture, adopted for security and privacy, that separates internal network requests from public internet requests, with each type routed to pools designed for that traffic.
Cloudflare has addressed these requirements with a custom rule builder that sits on top of its load balancing service. The feature lets customers write their own logic for traffic steering and origin selection, including compound and/or conditions. Path-based balancing, header-based steering, query-string matching, and cookie-based routing are all supported. A split-horizon design can be implemented by writing a rule that inspects the source IP address and routes to an appropriate pool accordingly.
The rule interface is built on the same open-source wirefilter execution engine that powers Firewall Rules, so the syntax will look familiar to existing users. Reusing that engine also means the feature inherits a production-tested library that already handles the performance and stability demands of other rule-based products.
Targeted rules for high-volume transactions
For an ecommerce operation, every transaction must complete quickly and reliably. As volume climbs, a single origin cannot handle all payment processing traffic, and shipping every request to a dedicated server regardless of location adds unnecessary latency. Rules can segment transactions by a value in the query string, and pair that with dynamic latency steering so the load balancer always picks the most performant path to the origin.
In practice, a rule that matches PS5 in the query string can direct those requests to a pool chosen by performance. The setup takes minutes and keeps transaction handling both fast and responsive to user experience.
Split-horizon DNS with two providers
Some customers deliberately use multiple DNS providers to increase resiliency and tighten security around different traffic types. Two providers help ensure availability during outages and allow a clean separation between internal office traffic and public internet traffic. The challenge has been routing those traffic types to the correct data centers without a flexible control mechanism.
A custom rule based on source IP address can implement split-horizon DNS in roughly five minutes. The rule overrides the pool or data center selection for matches, which is also useful when data centers are spread across regions that do not align with Cloudflare's 13 predefined regions. IP-based segmentation provides a granular form of geo-steering tuned to the needs of the business.
Two protocols, different capabilities
The load balancer supports both DNS-based and proxied balancing, and the two operate differently. DNS-based load balancing responds to queries from recursive resolvers, which are generally not the end user. Because DNS caches heavily at every level, a single query response may serve thousands of users, so customization is limited; the response can only be tailored to a limited degree.
Proxied load balancing runs its rules logic on every request that passes through the system. Since Cloudflare acts as a proxy, it can evaluate rules per request and access user-specific data. The practical result is that the available fields differ substantially between modes. DNS load balancing exposes fields like dns.qry.name, while proxied balancing exposes http.request.method. Some general fields, such as the load balancer name, are available in both.
How rule updates reach the edge
When a rule is configured, the API call first validates the conditions and actions. It checks that conditions reference known fields, that they are syntactically valid, and that they are not excessively long. Overrides are processed and tested against the load balancer's configuration to catch invalid combinations. Once validated, the rule is stored in the database.
From there, the load balancer's data and all associated rules are packaged into a single configuration and shipped to the edge. Updates propagate in seconds. At the edge, processing begins by loading that configuration, which holds static data such as rules, origins, pools, and steering policy. Dynamic data, including origin health and RTT measurements, is loaded when each pool is evaluated.
The rule execution itself is a loop: each condition is checked, and if true, the specified effects are applied. Because overrides are applied sequentially, more than one rule can modify a given setting during execution. That design lets users write shorter, modular conditionals and rely on rule ordering to refine behavior, rather than constructing long and brittle condition sets.
Next steps
Customers can begin building custom load balancing rules now, with guidance available in the developer documentation. On the roadmap are new fields for conditions and additional override options. Time-based conditionals—rules that apply only during specific hours or days—are also under consideration.
