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.

  • What happens if LaunchDarkly goes down?

    Outages happen, but LaunchDarkly uses a CDN to continue serving your feature flags uninterrupted in case something goes wrong with our backend servers. Even if the CDN goes down (we use Fastly, a widely-used CDN provider), your servers will continue operating with the last set of feature flag rules, so your customers will continue seeing the right set of features.

  • 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 *

  • 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.

See all 10 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 weird 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.

  • How do I add, remove, and manage my users in LaunchDarkly?

    You don’t have to send users to LaunchDarkly in advance – just set up your users in variation calls and you’re all set: .

    If we do not receive a request for a user in 30 days, then that user will no longer appear in the dashboard, but will still be stored in the database.   If we detect that the user is active again, then they will reappear in the dashboard with the latest set of attributes.  You cannot remove users manually from the dashboard.

    You may add individual users using the LaunchDarkly dashboard by navigating to a feature flag and adding users manually in the targeting tab.

  • What is the default rule?

    The default rule is a final rollout rule for any users that don’t match any of the previous sections on the Targeting tab, like individual targeting or custom rules.

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

    For simple percentage rollouts, you can just 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%.

See all 19 articles