This section addresses some common integration patterns, and provides guidance on how Geopulse On-Prem can be used to best effect.
The expected deployment architecture is multiple Geopulse On-Prem processes behind a load-balancer capable of server-side keep-alive connections, such as HAProxy. Each underlying process expects to process a high volume of requests over a small number of connections (approx. two connections per core is ideal).
Multiple Geopulse On-Prem processes placed behind a load balancer is the most simple pattern:
(The arrows above, and all other diagrams represent requests, with responses implicitly travelling in the opposite direction.)
An alternate approach is placing an Geopulse On-Prem process alongside each server process. This can simplify deployment, but requires sufficient resources on each server to host both processes.
A common need is to turn the Proximity and Audience responses into segments that can be consumed by an ad server. This can be accomplished one of two ways: (1) Proxying all requests to both Geopulse On-Prem and the Ad Server, or (2) the server proxys the segment information back to the client.
Here, the client wishes to show an ad, and makes a request to the server, which queries Geopulse On-Prem, and extracts the necessary information to construct the segments that will be passed to the Ad Server. The response from the Ad Server is proxied back to the client.
Alternately, the server can proxy the segment information back to the client, which will make the call to the Ad Server directly. These approaches are largely interchangeable, but the second approach may be somewhat less demanding on the server infrastructure.
Keeping the logic that transforms Geopulse On-Prem responses into ad segments on the server is critical, especially if the client is a mobile application. As it is difficult to predict how Audience and Proximity data may be employed in ad targeting, the logic should be kept where it can be easily updated.
Updated almost 3 years ago