In most cases, requests issued from the server side (backend integration) should be pinned to a specific Constructor data center.

There are two main types of requests that are important to understand the data center routing described below:

1. Behavioral events: requests typically dispatched from a tracking beacon to inform Constructor's machine learning platform as well as provide data to power personalization of results.

2. Requests for results: requests to retrieve data from Constructor's product discovery platform. For example, a search request for "dog toys."

Personalization & request routing

While all tracking & behavioral metrics influence the machine learning models powering Constructor's product discovery platform, personalization data specific to individual users is stored in the data center closest to the user (origin of request). This is to ensure personalization is applied in real time and to keep costs reasonable for customers.

To power fast and automatic personalization in Constructor's product discovery platform, both the requests for results from Constructor and the behavioral events (generally dispatched from the beacon) must resolve to the same data center.

Frontend integrations

In a frontend integration, the client requesting results from Constructor is generally a user’s browser or mobile device - the request origin is distributed across the globe wherever customers are located.

Both requests for results and beacon events are typically dispatched to ac.cnstrc.com in a frontend integration, which will route them to the closest data center to the requester.

As a result, the closest data center will build up personalization data for each individual user. Since requests map to the same data center as the behavioral events, Constructor can apply personalization on top of the results returned to the requester (browser or mobile device).

Backend integrations

In a backend integration, the client requesting data from Constructor is generally a server or series of servers within a specific geographic location.

In this setup, requests for results and beacon events cannot be sent to ac.cnstrc.com as the origin locations may differ. The requests for results originate from the backend server, where the beacon events are dispatched from the users browser or mobile device.

As a result, if the user is located in a different region than the backend web server issuing the request, the behavioral data from the beacon will be sent to a different data center than the one responding to the requests for results. In this case, personalization cannot be applied effectively.

To ensure results can be personalized in backend integration setups, Constructor recommends pinning all requests (for both results and behavioral events) to a specific data center.

The pinned data center should be geographically closest to the backend web server issuing requests for results from Constructor to optimize response times.

Important factors of note

• Should a specific cloud region experience an issue, Constructor will automatically failover to another to avoid a disruption of service. To ensure requests are prioritized effectively during this transition period, it is imperative that all required backend integration parameters are supplied with requests. Autoscaling will automatically take place in the failover region to handle any additional request load.
• As backend integrations require an additional network hop from Constructor’s servers to your servers before going to the user, requests will always be slower than if they were sent directly from the frontend to Constructor’s servers. Due to this additional network hop, some latency is introduced. It may be minimal if your users are all located near your data centers, or you have many globally distributed data centers, but there will always be some additional latency introduced. This is not a limitation of the Constructor service - it is inherent in adding an additional network hop to any system.

The preceding factors should be taken into consideration when deciding between a frontend or backend integration. In the majority of cases, Constructor recommends a frontend integration approach due to the ease of implementation and faster response times to the user.

If a backend integration is the selected option, it is critical to ensure that all required backend integration parameters are supplied with requests.