Affected: All SDKs
The behavior of the LaunchDarkly SDK in its default configuration can be affected by many external factors outside your control. Points of failure can include issues with internal networks, CDNs, or any cloud computing services.
In the case of an outage, all currently connected SDK instances will continue to operate as expected because the SDKs keep the last known flag data from LaunchDarkly cached locally. When new SDK instances are initialized, it will result in a failure to connect to LaunchDarkly. The SDK will continuously attempt to connect, and until it can, it will serve the fallback value when
variation is called (the fallback value is the optional last argument of the
We have ways to provide redundancy for all our SDKs, except for our mobile SDKs. The difficulty with mobile SDKs is that they are expected sometimes to have poor or no network connectivity, especially in the case of non-cellular mobile devices like tablets. To handle the inherently unstable nature of mobile environments, all of our mobile SDKs cache the most recent state for the 5 most recent users locally on the device.
bootstrap: “localstorage” option. This is the optimal solution if you expect your users to:
- Use your app offline frequently.
- Load the app under poor/unpredictable network conditions.
You can also use this solution if you want an easy way to be able to use the SDK without having to wait for it to initialize.
localstorage only offers redundancy to revisiting users.
Persistent Feature Store
To add redundancy to server-side SDKs you have three different options. The first option is to configure your SDKs to use a persistent feature store. The SDK will update the cache when it receives an update, and it will read from the cache when trying to evaluate flags. This provides the following benefits:
SDK can operate even if LaunchDarkly is unavailable.
You can evaluate flags without having to wait for the SDK to initialize its feature requester
The caveat is that the persistent feature store keeps flags cached in-memory but it reaches out to the cache to refresh the in-memory cache. This means that SDKs can be out of sync for up to X seconds, where X is the TTL of the cache.
Another option is “daemon mode." It involves combining both of the previous solutions. You set up a persistent feature store that provides redundancy if LaunchDarkly is down, configure both the SDK and the relay to the persistent store. Then you enable “daemon mode” on your SDKs, which causes them to disable their streaming connection entirely, and just rely on the relay to populate the persistent store whenever it receives an update. This offers the following benefits:
All of the benefits of both of the above solutions.
Further reduced network congestion due to fewer Redis write requests and because SDKs do not need to open streaming connections.
Relay proxy can initialize when LaunchDarkly is unavailable because it can read from the persistent store. This is likely the most optimal solution based on the aforementioned benefits. To read more about daemon mode, visit: .
If you have an extreme number of server-side connections, you may need to set up a few relay proxy instances behind a load balancer. Since the Relay uses a LaunchDarkly SDK to receive updates from LaunchDarkly, the Relay Proxy follows the same rules. If the Relay starts whilst LaunchDarkly is unavailable, then the Relay won’t be able to provide anything to the SDK instances that connect to it; if LaunchDarkly becomes unavailable while the relay is running, it will still serve flags from its in-memory cache. Using the relay offers the following benefits:
SDKs can initialize and operate normally.
SDKs could potentially initialize faster if the relay is “closer” than LaunchDarkly. This is usually the case if the relay is in the same architecture as your SDKs.
Reduce network congestion inside your architecture by having only one outgoing streaming connection to LaunchDarkly for each relay instance.