Routing strategies and benefits

You can route outgoing messages by creating routing rules. These routing rules apply to any message that is not sent on a specific channel.

Routing is a way to determine which channel a message should be sent through. Find out more about the role of routing in the introduction to the message bus architecture.

If you are sending messages through the local, database, or HTTP API, you can leave the channel ID empty and let the router assign a channel. If you are testing in the Auron Omni Manager, set the channel to “<< Any Channel >>” to apply routing rules.

You can find a description of how to add routing rules here. On this page we cover:

• Basics and benefits of routing;
• Basic routing rules with examples;
• Proportional routing rules with examples;
• Congestion based routing rules with examples.

Basics and benefits of routing

Routing rules consist of these parts:

• Message Type. The rule applies to all messages of this type;
• Target channel. The channel the message is sent through if the rule matches;
• Condition. A SQL expression that must match the message;

The first rule that matches is applied. If a message is not sent on a specific channel and does not match any routing rule, it is sent round-robin over any channel that matches the message type.

There are several reasons to set up routing rules. The most common are:

• Optimize for cost. Route messages to the most cost effective provider based on destination;
• Optimize for performance. Route messages based on congestion or load across channels;
• Select channel by message type. For example, route WhatsApp messages to a different provider than SMS messages;

The following sections describe common ways to create routing rules.

Basic routing rules

Basic routing rules are typically used to optimize cost or separate traffic by message type.

For example, send all messages that start with +31 or +32 to a Dutch operator (HTTPDUTCH), and all messages that start with +1 to a US operator (SMPPUS):

ToAddress LIKE '+31%' OR ToAddress LIKE '+32%'

ToAddress LIKE '+1%'

Messages that do not match any rule are sent round-robin over any available channel.

Another example routes email messages based on subject:

Subject LIKE 'Alert%'

1=1

The condition 1=1 is always true. This ensures all email messages are routed intentionally and do not fall through to round-robin behavior.

Proportional routing

There are several cases where proportional routing is useful.

Exclude a channel from automatic routing

For example, you have four SMS channels: SMPP1, SMPP2, SMPP3, and SMPP4. Only SMPP1, SMPP2, and SMPP3 should be used automatically. SMPP4 is reserved for manual testing.

You can define the following routing rules:

dbo.fnRouteProportional(RAND(ID), 3) = 0

dbo.fnRouteProportional(RAND(ID), 3) = 1

dbo.fnRouteProportional(RAND(ID), 3) = 2

These rules divide traffic evenly across three channels. The result of the expression is always 0, 1, or 2, so all messages are routed without falling through to SMPP4.

Route 75% to one channel and 25% to another

You can also distribute traffic unevenly. For example, send 75% of messages to SMPP1 and 25% to SMPP2:

dbo.fnRouteProportional(RAND(ID), 4) IN (0, 1, 2)

dbo.fnRouteProportional(RAND(ID), 4) = 3

This splits traffic into four equal parts. Three parts are routed to SMPP1 and one part is routed to SMPP2.

Details about this condition

Calling fnRouteProportional(RAND(ID), 4) translates to:
(CONVERT(INT, RAND(ID)*10E8) % 10000) % 4.

The intermediate step using CONVERT ensures a stable integer value for modulo operations. The multiplication and modulus steps help avoid patterns in the ID sequence and ensure a more even distribution.

Congestion based routing

With congestion based routing you can prefer one channel and overflow to another when needed.

For example, prefer HTTP1 because it is cheaper, but fall back to SMPP1 when load increases:

dbo.fnNumQueued('HTTP1') < 80

1=1

HTTP1 is used while its queue remains under the threshold. Otherwise messages are routed to SMPP1.