Streamlining Client-Server Integrations with Adobe Experience Platform Experience

adobe Experience platform (AEP)

Adobe Experience Cloud brings multiple marketing solutions in one platform to provide customers with a seamless experience. 

Each solution deploys an individual data collection SDK, so it can sends numerous requests to separate domains and edge servers to exchange data traffic with Adobe Cloud edge services.

This saturated network of client-server calls significantly delays the customer’s website performance and undercuts the overall end-user experience cloud.

It also slows the customer’s time-to-value since they’re required to learn, deploy and manage multiple implementations and data collection strategies.

Experience Edge is an Adobe Experience Platform initiative that provides a optimized gateway for requests who want to interact with other Adobe Experience Cloud services.

Target, Adobe Audience Manager, and Adobe Analytics. So, customers can simply deploy one SDK on their website to leverage server-side services, to improve performance, and streamline their path to value.

Experience Edge allows customers to leverage a shared data interface and services

Currently, each Adobe Experience service has its own domain and is called from the end-user’s web page or application.

In this implementation, secvices  provide a response before Service B and Service C so it can be called. Additionally, if a user gets tired of waiting and navigates away before Service C is called, 

there is a chance of inconsistent data between the services. then to make matters worse, it’s also difficult to accurately measure the quality and accuracy of the system’s flow.

to response to this problem, we developed a new Experience Edge that implements a common practice known as gateway.

As shown, this gateway receives a single, structured client request and orchestrates the requests to the various edge services.

 then aggregates the results and sends them back to the caller. From a client device perspective, so there is just one request and one response.

we can expect the following benefits, with the shared gateway streamlining server-side communication between services:

  • Drastically improved performance due to reduced overall latency, particularly over high-latency networks.
  • A virtually no implementation changes when customers enable a new service, eliminating the risk of complex, and error-prone client-side orchestration.
  • Easily evolved edge services since orchestration is entirely server-side — making upgrades transparent for customers.
  • Consistency of data that can be measured internally.

Architecture

below, the architecture for Experience Edge can be described in two logical sections: point of presence and edge location.

Point of presence

First the current implementation, the PoP simply hosts JAG. 

So, JAG is the reverse proxy for Experience Edge services, it’s a simple application that provide receives HTTPS requests and terminates the SSL connection as close to the end-user as possible.

This close termination shortens the path for the customer so thet can establish the SSL connection, accelerating the overall performance within Adobe Experience Platform.

it has extensive routing capabilities, also being able to act as a layer 7 router and load balancer across the edge locations that Adobe has deployed across the world. 

it uses server name indication (SNI) to manage considerably more first-party certificates for our customers than typical cloud load balancing networking solutions.

Edge location

JAG layer in the Experience Edge architecture and has four functions:

  • Forward the request to upstream services, such as Adobe Target, Adobe Audience Manager, or Adobe Analytics.
  • Handle the request and aggregate a single response to send back to the client.
  • Log the enhanced data collection event (i.e. request, enhancements, and upstream service decisions) to Adobe Experience Platform.

To standardize the I/O between these upstream services, we enlisted Adobe Experience Data Model (XDM) schemas to make each service pluggable and extensible.

 Such data consistency also allows us to easily develop new upstream services in the future.

Additionally, JAG a connect to a meta data service, which streamlines integrations with Edge services.

 Metadata service fetches a customer’s settings (e.g. organization ID, platform dataset ID, schema ID),

 configured using Adobe Experience Platform Launch, and updates thousands of Konductor instances across eight regions of the world in a matter of minutes.

Every millisecond counts: speeding up loading time with Konductor

One of our primary objectives with JAG and Konductor is to minimize latency for our customer’s webpages and optimize their time-to-value. 

To illustrate how Konductor achieves this, consider the following scenario:

When a new visitor opens a website, various JavaScript libraries must load and fetch an ID for the visitor’s device before the webpage can even render. 

If, for example, the site is using Adobe Target to customize the visitor’s content, the page must also wait until DIL.js loads, fetches, and delivers the right data.

In that case, each web page view generates the following delays:

So this means the minimum delivery time for this webpage is more than one second. 

Considering users abandon a website if it takes more than three seconds to load, this seemingly small delay in the customer’s website performance can be detrimental to their business.

In contrast, with Konductor these multiple calls will be streamlined into a single payload. In this scenario, a unified JavaScript library (xtag) loads and sends an optimized payload to the closest JAG instance, 

which then proxies to the appropriate Konductor instance using our optimized backend network.

eliminating the need for costly client-side orchestration and drastically reducing the overall delay. In this scenario, we have fewer calls with smaller latencies:

Our target is a total delivery time of under 500ms. According to initial testing, this goal is easily achievable when the network is controlled.

Implementation challenges

Minimizing latency

Since Konductor is the gateway that communicates with multiple services, it can expect to process millions of requests per second (globally). 

To ensure a significant throughput without adding latency to the request itself, our primary goal is to keep Konductor’s internal latency to a maximum of 5ms (on the 99th percentile).

Asynchronous first

When building an aggregation service that communicates with multiple upstreams, it’s paramount for the entire request and response handling pipeline to be fully non-blocking.

Subsequently, we used an event loop pattern (see figure below). Now, the cost of blocking the request thread until a response is received is replaced by the cost of opening a file descriptor and storing a callback in memory.

Reliability

We need to limit what is known as the « blast ratio ». For ex, if Adobe Audience Manager is experiencing issues.

 we want to isolate the connection so not to impact calls made to other Adobe Experience Cloud services. To pacify this blast ratio, we’re employing two main strategies:

In the future, both strategies will be configured based on the customer’s specific business needs.

What’s next for the Experience Edge gateway

While we are proud of our progress with JAG, we try continue to improve, test and adapt it to the needs of the evolving data landscape. 

For example, given the changes in user privacy, we now plan on transparently handling consent management within JAG to quickly 

check whether, the visitor’s device has consented to any data protection frameworks, such as GDPR and CCPA.

Finaly with plenty of progress already underway and many exciting innovations ahead, 

we’re excited for the future release of JAG and Konductor to further refine our customer’s experience 

it can drive a powerful new way of interacting with Adobe Experience Cloud and Experience Edge services.

Partagez sur :

Un projet ? Contactez nous