The Rollouts Developer Hub

Welcome to the Rollouts developer hub. You'll find comprehensive guides and documentation to help you start working with Rollouts as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    


If your stack is service-oriented or relies on microservices, there are some best practices and special considerations for implementing Rollouts 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. You implement those solutions one time, and your team doesn’t need to worry about them when they start testing. Handling the datafile 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 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.

Updated 6 months ago


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.