Performance, Speed, and Reliability

  • What happens if the SDK loses connectivity to LaunchDarkly?

    The SDK relies on its stored state to evaluates flags. By default the SDK first initializes with an empty state. When the SDK first initializes, it opens a streaming connection to LaunchDarkly. The initial response from LaunchDarkly contains the SDKs current state. The SDK will then keep this streaming connection open and when any change is made in the LaunchDarkly dashboard or via the Rest API, LaunchDarkly will send these changes to all currently connected SDKs.

    If the SDK ever loses connectivity to LaunchDarkly then it will continue attempting to establish a streaming connection until it succeeds. If you try to evaluate a flag before the SDK receives its initial state, or you try to fetch a flag which otherwise doesn't exist, then the SDK will return the fallback value. All SDKs provide synchronous (through blocking and/or polling) and asynchronous ways of waiting for the SDKs state to initialize.

  • Do you make a remote call every time a feature flag is requested?

    LaunchDarkly uses a novel streaming architecture to serve feature flags without making remote requests. We use server-sent events (SSE), a protocol for one-way real-time messaging, to send messages to your servers whenever you change the feature flag rules on your dashboard. SSE is widely used for server-to-browser messaging, but it works equally well for server-to-server communication. The SSE connection is all handled under the hood by our SDKs.

     
  • How do you ensure no latency?

    Our unique streaming architecture ensures that feature flags are updated nearly instantaneously, without introducing any latency to your site. LaunchDarkly’s performance is even faster than storing feature flags in your own database. We also have multiple layers of redundancy to ensure your users always receive a flag. 

  • Do I need to modify my firewall to use LaunchDarkly?

    In most cases no— our streaming connection only requires that your server be able to make an outbound HTTPS connection to *.launchdarkly.com.

  • What’s the overhead of a feature flag request?

    Almost nothing. LaunchDarkly’s SDKs use a streaming connection to asynchronously receive updates to your feature flag rules. Your actual feature flag requests are served from memory (or a Redis store, if you configure one). This adds less than 1 millisecond of latency to your page loads— about as fast as looking up a value in a hash table.

  • Do you support Redis caching?

    Yes, we support Redis caching. Our SDKs can be configured to use Redis as a persistent store, so even if an initial connection to LaunchDarkly fails, the last flag configurations will be used instead of the fallbacks.

    Redis caching is currently supported by the following SDKs:

    You may also use the LaunchDarkly Relay to handle feature updates, offloading that responsibility from the SDKs running in your servers.

See all 9 articles

How It Works

  • What is the targeting logic for percentage rollouts?

    The variation a user receives is determined based on the users key. When a percentage rollout is evaluated it generates a hash from the user's key, the user's secondary attribute if available, and a hidden salt attribute stored in the flag. The SDK then uses this hash to generate a percentage which is used in conjunction with the percentage rollout configuration to determine the variation a user receives.

  • Are anonymous users tracked when A/B testing?

    Yes, anonymous users are included in A/B testing. You will need to set an appropriate user key for anonymous users so that we can track each anonymous user separately; a session key might be appropriate. We don't display anonymous users on the Users screen because anonymous users couldn't be managed from LaunchDarkly, so they would only add clutter to the screen.

  • What happens when the MAU limit is reached?

    We do not impose a hard cap on MAUs. We'll never halt access or send you a bill based on overages. We allow for variance as we know a company's user base can grow unexpectedly over time. That said, we do limit the amount of users that will be saved in your dashboard. 

    When you exceed your MAU, your new users and changes to existing users (such as new attributes) will no longer appear in the dashboard. It's important to note that your users will continue to evaluate their flags correctly. This only impacts your ability to view user updates in the dashboard.

  • Do you have a REST API?

    All of our SDKs are built on top of the LaunchDarkly REST API. In fact, the entire LaunchDarkly web site is driven via the same API, so it’s heavily tested and complete. If you want to build a custom integration or export your data this API reference is the place to start.

  • What is the default rule?

    The default rule is a final rollout rule for any users that are not individually targeted and do not match any of your configured targeting rules.

    As with other rules, you can choose to serve a specific variation, or apply a percentage rollout to any remaining users.

    For a straightforward percentage rollouts, you can simply use the default rule for a feature flag. For example, to roll out the true variation to 50% of your users, set the default rollout rule to true 50% and false 50%.

     
  • How do you calculate confidence interval for A/B tests?

    We use a z-score.

See all 17 articles