---
schema_version: "1"
id: 38916f23ec75f69e3e2b5c69b88f975bad4dd3491deda2b7313ab319b4da42ad
title: Traffic Management for Multiple Upstream Services (Weighted)
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/gateway/1.13/policies-included-traffic-management.md
canonical_url: https://docs.mulesoft.com/gateway/1.13/policies-included-traffic-management
source_site: docs.mulesoft.com
content_type: documentation
content_hash: f9572c9e8413e3b3aabd4bf4e6f49f92b531489fb89d91693c7d355bc2f69001
description: MuleSoft Documentation Site
release: "1.13"
latest: false
---
---
product: Omni Gateway
version: 1.13
keywords: route weight, traffic management, multiple upstream services
---

# Traffic Management for Multiple Upstream Services (Weighted)

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

<table><colgroup><col> <col></colgroup><tbody><tr><td><p><strong>Policy Name</strong></p></td><td><div><div><p>Traffic Management for Multiple Upstream Services (Weighted)</p></div></div></td></tr><tr><td><p><strong>Summary</strong></p></td><td><div><div><p>Manages weighted API instance traffic to multiple upstream services from a single consumer endpoint</p></div></div></td></tr><tr><td><p><strong>First Omni Gateway version available</strong></p></td><td><div><div><p>v1.5.0</p></div></div></td></tr><tr><td><p><strong>Release Notes</strong></p></td><td><div><div><p><a href="https://docs.mulesoft.com/release-notes/gateway/policies/traffic-management-release-notes">Traffic Management for Multiple Upstream Services (Weighted)</a></p></div></div></td></tr><tr><td rowspan="4"><p><strong>Returned Status Codes</strong></p></td><td><div><div><p>No return codes exist for this policy.</p></div></div></td></tr></tbody></table>

> [!NOTE] The following information applies only to Omni Gateway running in Local Mode. To configure
> multiple upstream services for Omni Gateway running in Connected Mode, see
> [Multiple Upstream Services for Omni Gateway Running in Connected Mode](https://docs.mulesoft.com/api-manager/latest/create-instance-task-flex#traffic-management).

## Summary

Omni Gateway running in Local Mode supports API instances that expose multiple upstream services
through a single consumer endpoint.

Omni Gateway manages request traffic by using different routes that can each direct traffic to
multiple upstream services. Omni Gateway directs traffic to the routes by using the route order and
the individual route’s rules. Additionally, you can add a weighted percentage to each upstream
service within a route to manage the percentage of requests sent to the upstream service. For
information about configuring non-weighted traffic, refer to
[Traffic Management for Multiple Upstream Services](https://docs.mulesoft.com/gateway/1.13/policies-included-traffic-management-route).

API instances with multiple upstream services in Local Mode are configured by using `PolicyBinding`
YAML configuration resources. Each `route-weighted` resource defines a single route. To add
additional routes, add multiple `route-weighted` resources.

For a tutorial about how to publish an API instance with this policy applied, see
[Publishing an API Instance with Multiple Upstream Services in Local Mode](https://docs.mulesoft.com/gateway/1.13/local-publish-api-multiple-services).

> [!NOTE] Deploying APIs with multiple upstream services does not affect the
> [Outbound Transport Layer Security policy](https://docs.mulesoft.com/gateway/1.13/policies-included-tls-outbound). You can apply an
> Outbound TLS policy to each upstream service.

## Configuring Policy Parameters

Refer to the following policy definition and table of parameters:

policyRef: name: route-weighted config: routes:

- weight: <int> // REQUIRED, max\_value=100, min\_value=1 destinationPath: <string> // OPTIONAL,
  default: "/" destinationRef: name: <string> // REQUIRED rules:
- path: <URL-regex> // OPTIONAL, Example: (.\*) methods: <regex-string> // OPTIONAL, Example:
  GET|POST headers: <header-name>: <regex-string> // OPTIONAL host: <regex-string> // OPTIONAL

<table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Parameter</th><th>Required or Optional</th><th>Default Value</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><code>routes</code></p></div></div></td><td><div><div><p>Required</p></div></div></td><td><div><div><p>Empty</p></div></div></td><td><div><div><p>Array of API upstream services.<br>At least one upstream is required.</p></div></div></td></tr><tr><td><div><div><p><code>routes.weight</code></p></div></div></td><td><div><div><p>Required</p></div></div></td><td><div><div><p>N/A</p></div></div></td><td><div><div><p>Weight of total requests sent to this upstream service.<br>The percentage of traffic sent to that upstream service is the upstream service’s weight divided by total weight of all upstream services.</p></div></div></td></tr><tr><td><div><div><p><code>routes.destinationPath</code></p></div></div></td><td><div><div><p>Required</p></div></div></td><td><div><div><p>N/A</p></div></div></td><td><div><div><p>Path of the upstream service</p></div></div></td></tr><tr><td><div><div><p><code>routes.destinationRef.name</code></p></div></div></td><td><div><div><p>Required</p></div></div></td><td><div><div><p>N/A</p></div></div></td><td><div><div><p>Name of the upstream service as defined in the <code>Service</code> configuration resource</p></div></div></td></tr><tr><td><div><div><p><code>rules</code></p></div></div></td><td><div><div><p>Optional</p></div></div></td><td><div><div><p>Empty</p></div></div></td><td><div><div><p>Array of rulesets for this route.<br>Each route can support multiple rulesets.</p></div></div></td></tr><tr><td><div><div><p><code>rules.path</code></p></div></div></td><td><div><div><p>Optional</p></div></div></td><td><div><div><p>Empty</p></div></div></td><td><div><div><p>Request path that the route can service.<br>You can define only one “URI Template Regex" path for each ruleset. Only requests with the defined path are sent to this route.</p></div></div></td></tr><tr><td><div><div><p><code>rules.methods</code></p></div></div></td><td><div><div><p>Optional</p></div></div></td><td><div><div><p>Empty</p></div></div></td><td><div><div><p>Array that defines the types of request methods that the route can service.<br>You can select multiple methods for each ruleset. Only requests that are one of the defined methods are sent to this route. Supported values are <code>GET</code>, <code>POST</code>, <code>PUT</code>, <code>PATCH</code>, <code>DELETE</code>, <code>OPTIONS</code>, <code>HEAD</code>, <code>TRACE</code>, and <code>CONNECT</code>.</p></div></div></td></tr><tr><td><div><div><p><code>rules.headers</code></p></div></div></td><td><div><div><p>Optional</p></div></div></td><td><div><div><p>Empty</p></div></div></td><td><div><div><p>Array that defines what headers and regular expression value must be present for this route to service the request.<br>Only requests that meet all of the specified header requirements are sent to this route. Additional headers present in the request that are not specifically defined in the rules are ignored.</p></div></div></td></tr><tr><td><div><div><p><code>rules.host</code></p></div></div></td><td><div><div><p>Optional</p></div></div></td><td><div><div><p>Empty</p></div></div></td><td><div><div><p>Request host URL that the route can service.<br>You can define only one host URL for each ruleset. Only requests made from the defined host are sent to this route.</p></div></div></td></tr></tbody></table>

## How This Policy Works

The Traffic Management policy directs traffic to different sets of upstream services by using
multiple routes with a defined route order and individual rulesets to direct traffic to different
sets of upstream services.

In the following diagram, different routes manage requests to flight information databases and to a
customer service application. Route one has two upstream services defined, which directs 70% of
requests to a stable database and 30% of requests to a beta database.

![Omni Gateway manages the traffic to multiple upstream services](/mulesoft/current/en-us/gateway/1.13/_images/multiple-upstreams.png)

To achieve this configuration, bind two `route-weighted` resources to the exposed API instance. One
`route-weighted` resource directs traffic to the flight information database, and the other
`route-weighted` resource directs traffic to the customer service application.

### Upstream Services

You can use multiple upstream services in a single route to direct requests to similar services. For
example, to test the performance of a new beta upstream service without sending all traffic to the
new service, you can direct half of the traffic to a stable upstream service and half to the new
upstream service.

The upstream service within the route that each request is sent to is random and independent of any
previous request. The `routes.weight` value defines the chance of a request being sent to a
particular upstream service. The percentage of traffic sent to that upstream service is the
upstream’s `routes.weight` divided by the total weight of all upstream services. For example, if
there are two upstream services with weight `1`, each receives 50% of the traffic to that route. If
the weight values are `1` and `3`, one route would receive 25% of traffic and the other 75%.

Because any upstream service within a route can receive any request, all upstream services within
the same route must adhere to the same API contract.

### Route Rules

You can direct requests to different routes by using route rules. Requests must meet the rules for
only one of the rulesets in the route.

Rulesets refer to any combination of the four rules: `path`, `method`, `headers`, and `host`. You
can use multiple rulesets to support different combinations of rules.

All rules are optional. If a rule is not included in a ruleset, that rule is ignored. For example,
not specifying a host means that the route can service any host if the request meets the other route
rules. Not defining any rule means that the route can service every request.

If a request does not meet the rules for any route, Omni Gateway returns a `404` error code.

### Route Order

In addition to using route rules, you can direct requests to different routes by using policy
ordering.

To order policies, see [Ordering Policies](https://docs.mulesoft.com/gateway/1.13/policies-reorder)

Setting the policy order sets the order in which traffic is directed to the routes. Omni Gateway
directs requests to the first route if the request meets one of the route rulesets. Therefore, route
ordering is very important when a request can meet the route rules of multiple routes.

For example, in a configuration in which route one has the `GET` method defined as a rule and route
two has no route rules defined, all `GET` requests are sent to route one and all other requests are
sent to route two. If the route order was reversed and route one had no route rules, Omni Gateway
would direct all requests to route one before any `GET` requests could reach route two.

## See Also

- [Publishing an API Instance with Multiple Upstream Services in Local Mode](https://docs.mulesoft.com/gateway/1.13/local-publish-api-multiple-services)