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.
What happens if LaunchDarkly goes down?
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 instantly, 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. For example, in Java, you can configure a Redis store like this: http://launchdarkly.github.io/java-client/com/launchdarkly/client/RedisFeatureStore.html
You can also use the LaunchDarkly Relay to handle feature updates, offloading that responsibility from the SDKs running in your servers.
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'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.
Do you have a REST API?
Yes! 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, export your data, or want to use LaunchDarkly on a platform that we don’t currently support, 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
variationcalls and you’re all set: http://docs.launchdarkly.com/docs/getting-started .
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
truevariation to 50% of your users, set the default rollout rule to
How do you calculate confidence interval for A/B tests?
We use a z-score.