Microservices

If your stack is service-oriented or relies on microservices, you have two implementation options: use Optimizely as a service or include the SDK in every service.

Option 1: Use Optimizely as a service

For a centralized decision service, use Optimizely Agent, an open-source microservice that runs the Go SDK in a Docker container. Optimizely Agent exposes HTTP endpoints that map to all SDK functions.

This approach centralizes datafile management and event dispatching in one place, reducing setup and maintenance effort across your team.

The trade-off is that every decision requires a network call to Optimizely Agent, which adds latency compared to using an SDK directly in your services.

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

In this approach, you include the SDK in every service and rely on the deterministic, stateless nature of the SDKs to show users the same experience across services. You need to synchronize datafiles across all SDK instances.

The primary advantage is that all decisions are made in memory with no network call, preserving microsecond latency. This option is also more configurable because each team can configure the SDK to best fit their service.

The trade-off is higher maintenance cost because each team must manage their own SDK setup. For example, when Optimizely releases a new SDK version, you need to update every service where the SDK is installed.

📘

Note

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