While the Conditions Utility allows you to create routes based on logic using outputs from previous blocks, the Split Utility can create multiple routes to distribute load based on percentages.
You can create up to five routes at a time with a flexible distribution depending on your needs, like 50/50, 80/20, 8/15/42/35, etc.
This allows for a wide variety of use cases:
- A/B/C/.. testing of processors, configurations, third-parties, etc.
- Load distribution for more resilience at high volume.
- Cost optimization, for example sending 80% of traffic to your main provider, but keeping minimum volume commitments and sending the rest to the secondary provider.
- Traffic shifting, start with 100/0, and gradually update over time to 95/5, 90/10, 80/20, etc. until you reach 0/100 and have completely shifted traffic over.
What to consider when setting it up the Split Utility:
- You can create up to 5 splits, but need at least 2.
- It's mandatory to use the full 100% distribution across all splits, you can't save anything less than 100% or anything more than 100%.
- A split can have any value from
100- it's possible to assign
0to a split and use it to (temporarily) disable a split.
If you no longer want to use the Split Utility, you can remove it from your workflow. If you still have blocks assigned to splits, a dialog will ask if you want to retain the blocks from a specific split, or delete the entire utility and all subsequent routes.
Which split gets chosen during the execution of any given workflow is based on a random number generated at runtime. This is important to know, as there is no guarantee that the distribution is round robin. The workflow will not keep track of how many requests were routed through any given split or if the percentage that is set up is met exactly.
The more requests are sent in the closer the distribution nears the splits that are set up (law of large numbers). This also means if only a handful of requests are sent, the distribution can be very different. A setup of 50/50 with only two requests might still send both requests down the first split, making the actual distribution 100/0. Internal tests showed a standard deviation of 0.94% after 2 500 requests, falling to just 0.12% after 20 000 requests.
If you need an even more precise distribution than this, you can keep track of the various tiers in your backend, send in additional metadata, and branch based on that number using the Conditions Utility.
Now that you know how to use the Split Utility, you can create and use it within your workflows.