Architecture and operational guide

👍

Beta

Optimizely Edge Agent is in beta. Apply on the Optimizely beta signup page or contact your Customer Success Manager.

Content delivery networks (CDNs) are critical in delivering content globally. By caching content at geographically dispersed edge servers, CDNs significantly reduce latency and enhance user experience. See Content Delivery Networks and Optimizely Feature Experimentation for more.

Optimizely Edge Agent leverages this infrastructure to perform A/B testing directly at the edge, minimizing the dependency on central servers for decision-making. It is designed to provide a comprehensive, ready-to-deploy solution incorporating caching, cookie management, and visitor ID management.

Architecture overview

The architecture of Optimizely Edge Agent permits GET and POST HTTP request methods, adapting its functionality to different operational needs within a CDN-agnostic framework. See Introduction for more.

Modules and components

• OptimizelyProvider – Initializes and manages interactions with the Optimizely Feature Experimentation SDK, handling decision-making, event dispatch, and other SDK operations.

• CoreLogic – Acts as the central processing unit of the edge worker, managing request processing and coordinating between the edge worker and the OptimizelyProvider.

• CDN Adapters – Tailored modules for each CDN provider, ensuring optimal integration and functionality specific to each CDN's capabilities.

• RequestConfig – Manages and applies settings from request headers, query parameters, or POST body content across all system components.

• OptimizelyHelper – Provides utility functions for cookie serialization, user profile management, and flag updates based on the latest datafile.

GET requests

Get requests require a Feature Experimentation variable named cdnVariationSettings that must be configured for each variation:

const cdnVariationSettings = {
  "cdnExperimentURL": "https://apidev.expedge.com",
  "cdnResponseURL": "https://apidev.expedge.com/ui-elements",
  "cacheKey": "VARIATION_KEY",
  "forwardRequestToOrigin": "false",
  "cacheRequestToOrigin": "true",
  "cacheTTL": "60000",
  "isControlVariation": "true"
}

The cdnVariationSettings configuration

The cdnVariationSettings Feature Experimentation flag variable plays a vital role in the operation of the Optimizely Edge Agent, particularly when handling GET requests. This configuration dictates how the edge worker processes these requests, determining how content is fetched and served and how it integrates with broader testing strategies. The following list describes each component of the cdnVariationSettings:

• cdnExperimentURL – Serves as the identifier for the edge worker to match incoming GET requests against specific A/B tests. When a request URL matches the cdnExperimentURL, it triggers the decision-making process to determine which content variation should be delivered to the user. This ensures that only relevant traffic is subjected to the experiment, maintaining efficiency and focusing on resource utilization.
• cdnResponseURL– When a request matches an experiment, the cdnResponseURL specifies where the variant content is fetched from. This URL retrieves the appropriate variation content that is returned in response to the end user. It enables the edge worker to directly fetch and deliver customized content based on the experiment's outcomes, ensuring users receive the most relevant experience.
• cacheKey – Manages how responses are cached. If set to VARIATION_KEY, the edge worker constructs a cache key by appending the combination of the test's flag key and variation key to the cdnExperimentURL. This approach ensures that each variation is cached uniquely, permitting efficient retrieval on subsequent requests that qualify for the same variation. If a different value is provided, it is used as the cache key, offering flexibility in defining cache strategies.
• forwardRequestToOrigin – Controls whether the request, along with its decision data (such as headers or cookies), should be forwarded to the origin server. This is useful for testing backend services or for scenarios where the decision must be made at the edge, but the content generation or further processing is handled at the origin. This capability lets the edge worker act as a smart proxy, which can make decisions and then pass those along to the origin, enriching the backends' context about the user's experience.
• cacheRequestToOrigin – When enabled, directs the edge worker to cache the fetched or generated content for future requests. This minimizes the number of trips back to the origin server for subsequent requests by different users who qualify for the same experiment and variation, significantly enhancing performance and reducing load on the origin.
• cacheTTL– If configured, specifies the cache Time-to-Live (TTL) for content that is fetched from the origin and returned to a client.
• isControlVariation – Identifies whether the settings correspond to the control group in an A/B test. Used for analyzing the effectiveness of variations against a baseline, ensuring that the control variation is treated distinctly and results are measured accurately.

Each of these settings in the cdnVariationSettings optimizes the delivery and effectiveness of A/B tests at the edge and also ensures that resources are used judiciously and user experiences are personalized without unnecessary latency or overhead. This comprehensive approach lets you implement robust, scalable, and efficient A/B testing strategies directly at the edge. For information about the cdnVariationSettings, see Edge Mode flag variable configuration.

Benefits of A/B testing at the edge with Optimizely Edge Agent and cdnVariationSettings

Optimizely Edge Agent, enhanced by the cdnVariationSettings configuration eliminates the complications normally associated with deploying and managing edge-based A/B tests, especially around worker redeployment and content caching management.

• Streamlined A/B test deployment – Ability to initiate and modify A/B tests without the need for redeploying the workers. Changes to testing parameters, such as targeting different user segments or varying content delivery, can be dynamically updated in the JSON configuration object. This flexibility lets you adapt your strategies based on real-time insights and changing business needs without the downtime typically associated with deploying new code or configurations at the edge.
• Automated content caching management – The cdnVariationSettings simplifies the management of content caching on a per-variation basis. By specifying parameters like cdnResponseURL and cacheKey, you can define how each variation should be cached at the edge. This ensures:
  • Variation-specific caching – Each test variation has its unique cache, determined by the cacheKey configuration. This ensures that users consistently receive the correct version of the content as per the test's segmentation rules, maintaining the integrity of the A/B test results.
  • Efficient resource utilization – Caching content directly at the edge reduces the need for repeated queries back to the origin servers for the same content, thus optimizing bandwidth and reducing server load. This efficiency is particularly crucial during high-traffic periods or for resource-intensive content.
  • Rapid content delivery – Serving cached content from edge locations closest to the users not only speeds up content delivery but also enhances the user experience by providing faster response times. This immediate responsiveness is vital in maintaining engagement and reducing bounce rates during A/B tests.
• No redeployment required – Updates to A/B tests, including pausing, stopping, or updating variations, do not require worker redeployment. This significantly reduces operational overhead and accelerates the pace of experimentation.
• Decentralized decision making – Decisions about which content variation to serve are made directly at the edge, closer to the user. This not only improves performance but also enables more granular and accurate testing based on real-time user interaction data.
• Scalability and flexibility – The system scales to handle increased traffic and more complex testing scenarios without additional strain on central infrastructure, thanks to the distributed nature of edge computing.

Sequence of operations

The sequence of operations for GET requests in the edge worker are:

1. Request evaluation – Upon receiving a GET request, the edge worker evaluates if the request matches the conditions in the cdnExperimentURL.

2. Decision making – If a match is found, the edge worker utilizes the OptimizelyProvider to determine the appropriate variation based on user cookies and experiment configuration.

3. Content fetching and caching – Based on the cdnResponseURL and caching directives (cacheRequestToOrigin), the edge worker fetches the variation content from the specified URL or retrieves it from the cache.

4. Response modification – The response includes headers or cookies reflecting the decision, ensuring consistency in the user experience across multiple requests.

5. Forwarding and caching logic – If forwardRequestToOrigin is true, the request is forwarded to the origin server with modified headers and cookies. If not, the response is served directly from the edge cache to minimize latency.

POST requests activate the serverless functionality of the edge worker, operating independently of cdnVariationSettings:

1. Request processing – POST requests are processed directly by the edge worker.

2. Agent functionality –Optimizely Edge Agent functions as a serverless edge microservice, interfacing with the backend through the Optimizely Feature Experimentation API.

3. Response management – Responses are returned directly to the requester, ensuring efficient handling of dynamic content requests.

REST API and key-value store integration

The edge worker incorporates a REST API for interacting with the key-value (KV) store, enabling advanced management of experimentation flags and datafiles:

• Flag key management – Stores a subset of flag keys from the datafile to control which experiments are activated during GET request evaluations.

• Datafile management – Supports storing and automatically updating the datafile in the KV store using webhooks when modifications occur. The edge worker can load the datafile directly from the KV store or download it from the Optimizely CDN.

Benefits of edge-based A/B tests

Implementing A/B testing at the edge offers multiple technical advantages:

• Immediate decision making – Reduces latency by making decisions at the point of contact, avoiding back-and-forth with central servers.

• Scalability and efficiency – Naturally scales with traffic increases, managing load without significant infrastructure changes.

• Reduced costs – Lowers bandwidth costs and operational overhead by reducing data transfers to and from the origin server.

Comparison with traditional server-based architectures

Utilizing an edge-based serverless architecture offers significant improvements over traditional server setups like Kubernetes or Amazon EC2 instances:

• Infrastructure simplicity – Reduces the complexity and cost of maintaining and scaling traditional servers.

• Enhanced performance – Provides lower latency and higher throughput by processing data at the edge.

• Operational efficiency – Decentralizes decision-making processes, enhancing overall system responsiveness and efficiency.

Comprehensive list of experiments by request type

The type of experiments that can be performed using Optimizely Edge Agent depends on whether they are initiated through a GET or POST request. Each request type supports different testing methodologies and strategies tailored to the capabilities and scenarios best suited for each.

Experiments for GET requests

• URL-based targeting tests – Tests where the content or experience varies based on the specific URL visited by the user.

• User segmentation tests – Segmenting users based on criteria like geography, device type, or session activity and delivering tailored content accordingly.

• Behavioral targeting tests – Dynamic content changes based on user interaction patterns or historical behavior.

• Performance tests – Variations in CDN configurations or file sizes to evaluate performance impacts on user experience.

• Visual and UX design experiments – Variations in layout, color schemes, or menu elements to test visual appeal and usability.

• Content personalization tests – Customizing content such as text, images, or offers based on user data or past interactions.f

Experiments for POST requests

• Backend functional tests – Evaluating different algorithms or backend services without altering the user-facing elements of the application.

• API behavior tests – Testing how different API responses affect app behavior or server-side processing.

• Dynamic content generation tests – Generating different responses from the server based on the input received from POST requests.

• Capacity and stress tests – Understanding how systems perform under varying loads by simulating different traffic patterns or data inputs through POST requests.

• Security and robustness tests – Verifying how changes in security settings or request handling rules impact system stability and security.

Benefits of caching variation content at the edge in an A/B test

Caching variation content at the edge brings several significant benefits, especially in the context of A/B testing:

• Improved performance – Caching content close to the user reduces the distance data travels, decreasing load times and improving overall website performance. This is crucial in A/B testing, which aims to provide a seamless user experience across variations.

• Reduced server load – By caching content at the edge, requests for repeated content are served directly from the cache rather than hitting the origin server each time. This reduces the load on central servers, enabling them to handle other critical operations more efficiently.

• Cost efficiency – Reducing the number of requests to the origin server not only minimizes bandwidth costs but also reduces the computational load, which can translate into lower operating costs for large-scale deployments.

• Scalability– Edge caching makes it easier to scale applications as the user base grows. Because the edge handles much of the content delivery, applications can sustain more users without a proportional increase in origin server resources.

• Reliability and uptime – With content cached at multiple edge locations, the impact of a single point of failure is minimized. This redundancy increases the overall reliability of the application and ensures higher uptime, which is vital during A/B tests to maintain test integrity.

• Quick iteration on experiments – Faster content delivery lets you get feedback quicker on test
  variations. Marketers and developers can iterate more rapidly, adapting to user responses and refining strategies in near-real time.

• Consistency in user experience – Edge caching ensures that when a user is bucketed into a variation, they continue to receive the same version throughout the test duration, enhancing the consistency of the experimental data.

These benefits demonstrate why caching variation content at the edge is integral to conducting efficient, effective, and scalable A/B tests, making it a preferred strategy for businesses focused on optimizing user experiences through rapid experimentation and personalization.