Optimizely will be sunsetting Full Stack Experimentation on July 29, 2024. See the recommended Feature Experimentation migration timeline and documentation.

Dev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunitySubmit a ticketLog In
GitHubNuGetDev CommunitySubmit a ticket
These docs are for v2.0. Click to read the latest docs for v3.0.


If your stack is service-oriented or relies on microservices, there are some best practices and special considerations for implementing Full Stack that you should understand.

Service-oriented sites have two implementation options: use Optimizely as a service or include the Optimizely SDK in every service. This topic describes the advantages and disadvantages of each option.

Option 1: Use Optimizely as a service

In this approach, you would use Optimizely as a service by wrapping the SDK and interfacing with network endpoints.

This approach has the advantage of centralizing challenging tasks like datafile management and event dispatching. You implement those solutions one time, and your team doesn’t need to worry about them when they start testing. Handling the datafile and event dispatches to Optimizely in only one place reduces the overall setup and maintenance effort.

The disadvantage of this approach is that a network call is required to determine whether to activate an experiment or to grant a user access to a feature. Communicating with the SDK as a service has higher latency than including it directly in your services (option 2).

Option 2: Install the Optimizely SDK in each of your core services

In this approach, you would include instances of the Optimizely SDK in every service and rely on the deterministic and stateless nature of the SDKs to show users the same experience throughout each service. If you choose this option, you need to synchronize datafiles across all instances of the SDKs.

The primary advantage of this option that it preserves near-zero latency decisions by the SDK. It is more performant than option 1 because all the decisions are made in memory without the need for a network call to a service. This option is also more configurable: each team sets up the SDK as best fits their implementation.

The disadvantage of this option is that teams must implement their SDK themselves, and maintenance costs increase. For example, if Optimizely releases a new SDK, you’ll need to update the SDK in every service where you have it installed.



Although this approach requires synchronizing the datafile across your services, most customers find that they don’t need to enforce exact synchronization everywhere. As long as each implementation has a relatively short cache expiration, occasional brief discrepancies are okay.