Balance runs, cycles, and bundles

Transcript

Although we may want to process all records as often as possible, that may not be best practice due to system limitations or API restrictions. When looking at the total volume of records processed we need to balance and consider the frequency of the runs, the number of cycles per run, and the max number of records in a single cycle. If we decide to increase the frequency of the runs on our scenario, that will in fact increase the total volume of records processed. However, this increases the amount of traffic to a third party and potentially will push back a 429 error from that API from being pinged too often or too much. Every API has a different limit on how often you can call to it so it’s important to keep that in mind when building your scenarios to avoid any errors. The next thing you might decide to do is increase the number of cycles per run, which will in fact increase the total volume of records processed. This will do the same thing as before and increase the number of calls to a third party application during a scheduled run but there’s a positive impact on dealing with errors and we’ll cover this in a future course. Finally, if we increase the max number of records in a single cycle, this will in fact increase the total volume of records processed. This returns more records in a single call to the third party but may make error management more difficult. More to come on that when we discuss error handling in future courses. Ultimately, there’s a little bit of art and science that goes into how your schedule is structured, the frequency of your runs, the number of cycles per run, and the max number of records in a single cycle. It’ll take experience and knowledge of the APIs or the third party applications that you’re calling to to determine what’s best per scenario. -