Overview

ABetterChoice server SDKs enable you to run experiments and check feature flags locally on your server.

Generally available today: the Go server SDK. The C++ server SDK is listed under Settings → SDK&Key as Coming soon. If your server runtime is not Go, call the platform through the HTTP API in the meantime.

Using an ABetterChoice server SDK involves three steps:

1. Initialization

Upon the startup of your application server, you need to initialize the platform SDK with your project ID and API access key. The SDK then sends a request to the nearest of our globally deployed configuration servers to fetch necessary configurations, such as experiment allocations and rules. These configurations are essential for evaluating experiments and feature flags. After initialization, the server SDK polls the platform config servers for configuration updates every 3 seconds and stores them locally to ensure rapid result evaluation.

2. Evaluating Experiments and Feature Flags

When the customer code calls the platform SDK via the getExperiment or getFeatureFlag API, the SDK uses the locally stored configurations to calculate the experiment and feature flag results. As all evaluations occur locally, the latency is minimal.

3. Logging Experiment Assignment Exposure

For experiments and feature flags with enabled experimentation, we offer two methods of logging exposures. Firstly, the SDK will automatically log exposures when you call the getExperiment or getFeatureFlag APIs. Secondly, in certain scenarios where you need to log exposures manually at a later time, we provide a standalone API, LogExperimentExposure. In both methods, the exposures are accumulated locally and periodically flushed to the message queue.

FAQs

Where does the server SDK evaluation occur?

All evaluation logic occurs within the SDK.

What is the overall latency for the server SDK APIs?

As the evaluation occurs within the SDK using configurations stored in the local cache, the latency for evaluation is extremely low.

How long does it take for my update to reach the users?

The update delivery time consists of two parts: the time taken to deliver the update from the DB to our global config servers, and the time taken for the updates to sync to the platform SDK via its periodic poll. The total delay would be around 15 seconds.

How does the platform ensure system reliability?

the platform config servers are globally deployed across multiple regions and can auto-scale to handle traffic spikes.