Round Robin
Round Robin Routing for Traffic Distributor
Round Robin is the most common Traffic Distributor routing method. It sends incoming requests to the configured backends in rotation according to their assigned traffic weights.
Identical content required: Use Round Robin only when both backends contain the same application data and content, because user requests can be handled by either backend.
On this page
How Round Robin Works
Traffic Distributor processes incoming requests in sequence and selects a backend according to its predefined priority. Each priority is represented as a percentage of the total traffic.
- Requests are rotated between the available backends.
- The assigned percentage determines how frequently each backend is selected.
- Both backends remain active unless one of them receives a 0% share.
- The routing ratio can be adjusted as application capacity or operational requirements change.
Round Robin helps distribute load across several application copies and can improve availability when both backends are healthy and contain matching content.
Backend Weights and Priorities
The Traffic Distributor installation and configuration form allows the traffic share of each backend to be expressed as a percentage.
50 / 50
Equal Distribution
Requests alternate between the two backends, providing balanced resource usage.
70 / 30
Weighted Distribution
The first backend processes approximately seven of every ten requests, while the second processes three.
100 / 0
Single Active Backend
All traffic is directed to one backend while the other receives no new requests.
Traffic Distribution Examples
With equal weights, every next request is normally routed to a different server:
50% / 50% example: Request 1 goes to Backend A, request 2 to Backend B, request 3 to Backend A, and the sequence continues.
With a weighted ratio, the distributor sends a larger share of requests to the higher-priority backend:
70% / 30% example: Out of ten consecutive requests, approximately seven are processed by Backend A and three by Backend B.
With a 100% allocation, only the selected backend is included in the active routing configuration and processes all incoming traffic.
Typical Use Cases
- Distribute traffic evenly between two identical application environments.
- Send more requests to a backend with greater capacity.
- Gradually shift traffic from an old application environment to a new one.
- Direct all traffic to one backend during maintenance or an invisible application update.
- Migrate an environment to different hardware without interrupting user access.
Configuration Recommendations
- Keep the application content and configuration identical on both backends.
- Use shared storage or data synchronisation when user-generated files must remain consistent.
- Ensure both backends connect to compatible or shared database services.
- Set the ratio according to the real processing capacity of each backend.
- Verify health checks before directing production traffic to a backend.
- Use Sticky Sessions instead when an application stores session state locally and cannot share it between backends.
Session handling: Round Robin does not guarantee that a user’s next request will reach the same backend. Store sessions centrally or use Sticky Sessions when session affinity is required.