Use case: limit throughput with External Data Sources and Custom Actions limit-throughput
Description of the use case
51黑料不打烊 Journey Optimizer enables you to send API calls to external systems using Custom Actions and Data Sources. These features integrate seamlessly with external platforms, enhancing the flexibility and scope of journeys.
You can achieve this through:
-
Data Sources: Retrieve information from external systems and apply it within the journey context. For example, retrieve real-time weather data for a profile鈥檚 city to adjust the journey flow, such as sending location-specific offers based on the weather.
-
Custom Actions: Send information to external systems. For example, use Journey Optimizer鈥檚 orchestration capabilities to send emails via an external email solution, utilizing profile data, audience segmentation, and journey context.
When using external data sources or Custom Actions, protect external systems by limiting journey throughput. Journey Optimizer supports throughput of up to 5,000 instances per second for unitary journeys and up to 20,000 instances per second for audience-triggered journeys.
For Custom Actions, throttling capabilities are available at the product level. Refer to this page.
For external data sources, define capping limits at the endpoint level using Journey Optimizer鈥檚 Capping APIs to prevent external systems from being overwhelmed. Requests exceeding the limit will be dropped. This section provides workarounds to optimize throughput and minimize dropped requests, ensuring smooth integration with external systems.
For more information on integrating with external systems, refer to this page.
Implementation
For audience-triggered journeys, adjust the reading rate of the Read Audience activity to directly control journey throughput. This setting defines how many profiles can enter the journey per second. Read More.
You can set the throughput value between 500 and 20,000 instances per second. If a lower rate than 500 instances per second is required, use 鈥減ercentage split鈥 conditions along with wait activities. These actions divide the journey into multiple branches and control the flow of profiles in each branch at specific intervals.
Example: audience-triggered journey
Consider an audience-triggered journey with a population of 10,000 profiles that sends data to an external system supporting 100 requests per second:
-
Define the Read Audience activity to process profiles at a throughput of 500 profiles per second. This configuration ensures the system processes all 10,000 profiles in 20 seconds. For example:
- At the first second, 500 profiles are read.
- At the second second, another 500 profiles are read, and so on.
-
Add a 鈥減ercentage split鈥 Condition activity with a 20% split. This ensures 100 profiles are directed into each branch per second.
-
Add Wait activities with specific timers in each branch. For example:
-
In Branch 1, set the wait time to 30 seconds. Profiles are processed as follows:
- At the first second, 100 profiles wait until the 31st second.
- At the second second, another 100 profiles wait until the 32nd second, and so on.
-
In Branch 2, set the wait time to 60 seconds. Profiles are processed as follows:
- At the first second, 100 profiles wait until the 61st second (1 minute, 1 second).
- At the second second, another 100 profiles wait until the 62nd second (1 minute, 2 seconds), and so on.
Since all profiles are read within 20 seconds, there will be no overlap between branches. For example:
- Between the 31st and 51st seconds, all profiles in Branch 1 are processed.
- Between the 61st second (1 minute, 1 second) and the 81st second (1 minute, 21 seconds), all profiles in Branch 2 are processed.
-
-
To further optimize processing, consider adding additional branches (for example, a sixth branch) to reduce the number of profiles per branch. This approach is particularly helpful when the external system has strict limits, such as supporting only 100 requests per second.
Additional protective measures
Enable Capping capabilities to safeguard your system from exceeding throughput limits.