High Concurrency Mode for REST API

If your app sends many "goals" to measure various conversion events, the Conductrics REST API design presumes that the goals won't be sent in separate REST API calls that fire at the same moment for a given visitor/session identifier. Rather, the assumption is that such goal calls would be "batched" into a single REST API call. So, if there are 10 goals that might fire at a given moment on your side, the assumption is that all 10 goals would be sent in one REST API call, rather than 10 separate HTTP requests of one goal each (or 5 HTTP requests of two goals each, etc).

However, due to the nature of your app or implementation, it may be the case that you can't easily do this "batching". Your app may therefore end up sending many separate REST API calls for a given visitor at the same moment in time, and due to the nature of HTTP the requests can "criss-cross" in flight, meaning that there is no guarantee that Conductrics will receive them in the exact order that they were sent.

If that is the case, AND your app has a high level of overall traffic, Conductrics can enable a "High Concurrency Mode" which changes the behavior of the REST API slightly, so that it can queue and process the "concurrent" requests in order.

👍

There shouldn't be a need to use High Concurrency Mode if your goal calls are "batched" for a given visitor. Batching the goal calls also reduces network utilization and general "chattiness", so Conductrics recommends batching up the goal calls if possible. Please feel free to contact Conductrics if you have questions about this - we are happy to help you decide what's best for your implementation.

How Does High Concurrency Mode Change Behavior?

There are some minor changes in REST API behavior when High Concurrency Mode is enabled.

Normally, Conductrics processes goals immediately, during the REST API call, and the API call's response includes information about which agents "accepted" the goal.

In High Concurrency Mode, the goal processing is deferred for a few seconds, after the REST API call has completed. The goal calls are then "replayed" in order internally within Conductrics. This means that the call's response doesn't know which agents "accepted" the goal yet, which in turn means that there are some minor changes in API behavior.

In Normal Mode

• REST API calls return information about which agents "accepted" the goal, in the rs portion of the API reply as discussed under "Sending Rewards" in the Runtime API Reference.
• Rules that use Conditions based on whether a Goal has been reached for the current visitor work right away, even during the current API call.

In High Concurrency Mode

• REST API calls don't include any information about which agents have "accepted" the goal. The items portion of the API reply will not include any feedback for the goals sent. This means that if the "commands" sent to the REST API were for goals only, the items array in the API response will be empty.
• Rules that use Conditions based on whether a Goal has been reached will not work right away. For instance, if you make a REST API call that sends a goal and also requests a selection from an agent, and the agent has a condition/rule that includes/excludes the visitor based on whether the goal has been reached, the condition will be evaluated as if the goal hasn't been sent yet (because the determination whether to accept the goal is still pending).
• There is a delay of a few seconds before goals are registered in the Conductrics reporting.

📘

High Concurrency Mode can only be enabled by Conductrics at this time. Feel free to reach out to us if you'd like to discuss using it.

How Do I Know if High Concurrency Mode is Enabled?

Go to Settings > Deploy Targets in the Conductrics Admin. If High Concurrency mode is enabled, you will see an orange "High Concurrency" marker next to the Deploy Target for the REST API.