Skip to main content

How to improve implementation to be resilient to network failures

Affected: All SDKs

Overview

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 variation method). Please read further for best practices for mobile SDKs, client-side JavaScript-based SDKs, and server-side SDKs.

Solution

Client-side SDKs

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.

JavaScript-based SDKs

By default, JavaScript-based SDKs cache the most recent state in-memory, but you can cache it locally to the device similar to the way mobile works. The key difference is that you cannot change the user object to a new user or the SDK will serve the fallback value for all flags until it has finished fetching the flags for the new user. This is achieved by configuring the SDK with the bootstrap: “localstorage” option. This is the optimal solution if you expect your users to:

  1. Use your app offline frequently.
  2. 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.

It is also possible to evaluate the user’s flags server-side and render them into the page that you send to your users, then bootstrap your JavaScript-based SDKs with those values. This is optimal in any situation where you are serving the page to the user over the internet. This also provides redundancy to all users, while bootstrapping from localstorage only offers redundancy to revisiting users.

For more information about bootstrapping, read: Bootstrapping

Server-side SDKs

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.

To read more about using a persistent feature store, visit: Persistent data stores

Daemon Mode

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: Persistent data stores.

Relay Proxy

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.

Note that the cost of setting up the Relay Proxy may not be worth it, depending on your use case. To read more about the Relay Proxy, visit: The Relay Proxy

Was this helpful?