The LaunchDarkly platform unlocks modern software development by helping organizations release features, migrate technologies, target audiences, establish experiments, and enhance mobile launches. But you might be wondering, "How does it actually work?"

Let's walk through LaunchDarkly's core architecture to show you how it can support you and your teams develop your best applications.

The Flag Delivery Network

The LaunchDarkly Platform is a globally available solution, which means that its core capabilities are available anywhere at any time. How? Through a combination of a global Content Delivery Network (CDN) and internal infrastructure that we call the Flag Delivery Network (FDN). Applications utilize our language and SDKs to connect to this FDN in order to evaluate flag values and rules and values in real-time.

LaunchDarkly's FDN is supported by 100+ globally distributed points of presence that cache and serve flag and rules payloads. Combine that with support for 25+ SDKs and it's likely that no matter what type of application you are building, LaunchDarkly can support it anywhere in the world! That's a big footprint to cover, which inevitable leads to the question, "How resilient is LaunchDarkly and what happens if it goes down?"

LaunchDarkly Resiliency and Recovery

Rather than asking the question, "What happens if LaunchDarkly goes down?" A better question might be, "What happens if my application can't reach LaunchDarkly?" Outages happen, an outage in LaunchDarkly just means a temporary loss of connection from your application to the LaunchDarkly platform, the same as if the application itself goes down. Fortunately, LaunchDarkly is prepared for either scenario because we take a multi-level approach to flag delivery.

Multi-AZ Architected LaunchDarkly Core

LaunchDarkly's platform is built for redundancy and a high failure tolerance. LaunchDarkly's infrastructure is deployed across mutiple Availability Zones (multi-AZ) that ensures continued uptime in the event a specific instance or region becomes unavailable.

Globally Available CDN

In addition to ensuring that LaunchDarkly's core infrastructure is up and running at all times, LaunchDarkly also utilizes a series of Content Delivery Network access points that span the globe. Even in the event that one is unreachable, applications will be able to retrieve flag values and variations from the next nearest available access point.

Relay Proxy (optional)

LaunchDarkly's relay proxy is a great tool for organizations with applications that would require a high number of connections with the LaunchDarkly platform, i.e. microservices, or are located in networks with strict access requirements. Microservice applications can reach very large deployment scales and ensuring consistency across replicas is critical. The relay proxy is a simple Go-based application that can be deployed within the same environment as the application retrieving flag values. The relay proxy is not required and may not be needed, it depends on the structure of your application.

Self-recovering SDKs

Sometimes problems can occur at the application layer rather than in the connection point between the application and LaunchDarkly. Errors like a failed initialization with the SDK or an interruption of service that temporarily block the application from properly connecting with LaunchDarkly. Fortunately, all of LaunchDarkly's SDKs are self-healing, meaning that they will attempt to re-connect to LaunchDarkly automatically.

In-memory Flag Value Cache

Once the application has successfully initialized the SDKs and connected to LaunchDarkly the most recently retrieved flag value will be store in-memory. This means that if there is an interruption in service, the application will remain in whichever state it is currently serving using the last value it received. Once a connection is re-established, the memory cache will be updated to reflect any changes in the flags.

Fallback Flag Values

Developers also have the option of declaring a default value when instructing the code to evaluate a flag. This ensure that some state will be served in the event that initialization fails and the flag value is currently unreadable by the application.

Lifecycle of the SDK

We've mentioned a couple of times, the term "initialization", but what does that mean? The LaunchDarkly SDK initialization how the application tells LaunchDarkly what type of application is being used, e.g. JavaScript, Go, Python, Swift, etc., and provides the necessary credentials for authenticating the application with a specific LauchDarkly project.

SDK intialization is configured within the application and will occur once that application has been deployed. The SDK connects to the Flag Delivery Network (FDN) and flag values become available in about 25ms.

Secure Flag Evaluations

Security is critically important to modern applications and LaunchDarkly extends that security mindset to flag evaluations, offering a "secure mode" for feature flags. With LaunchDarkly's secure mode, feature flags can be hidden and are not discoverable within the application code, users cannot unpack or inspect flags for alternative values, user data and the underlying targeting rules are protected. LaunchDarkly supports flag evaluations on both the client side and server side of an application.

Client side flags are delivered directly to the consuming device and only the flag values for that specific device will be discoverable. Server side flags retrieve the flag values for all contexts and rules for a given environment. This is one of the reasons that protecting your Server-side SDK key as a sensitive credential is extremely important. It is recommended that you restrict access to your server side SDK key.

Delivery Flag Changes

We've discussed the infrastructure support LaunchDarkly and how flags are delivered to applications, but how quickly does this all happen? In a matter of milliseconds. As mentioned earlier, the initial flag deliver happens about 25ms after SDK initializations. Following initialization, LaunchDarkly supports two mechanisms for evaluating flags: Streaming and Polling.

Streaming connections are high speed, real-time evaluations of flags. The application maintains an active connection with the LaunchDarkly platform and retrieve changes in flags within 200ms. Polling connections, alternatively are used in circumstances where maintaining an open connection is not possible, i.e. with mobile SDKs. Polling connections instead periodically reach back out to LaunchDarkly to assess any changes, conserving both data and power.

Conclusion

After reading this, you can see that LaunchDarkly is a fast, secure, and globally available platform for delivering flag values and rules to any type of application. Using LaunchDarkly ensures that all areas of your organization are able to build and deliver modern software solutions with less risk.