Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Key Concepts

This section defines the fundamental concepts and metrics used when designing resilient LaunchDarkly integrations.

Initialization

Initialization is the process by which a LaunchDarkly SDK establishes a connection to LaunchDarkly's service and retrieves the current flag rules for your environment. During initialization, the SDK performs these steps:

  1. Establishes a connection to LaunchDarkly's streaming or polling endpoints
  2. Retrieves all flag definitions and rules for your environment
  3. Stores these rules in an in-memory cache
  4. Begins listening for real-time updates to flag rules

Until initialization completes, the SDK cannot evaluate flags using the latest rules from LaunchDarkly. If a flag evaluation is requested before initialization completes, the SDK returns the fallback value you provide.

Initialization is a one-time process that occurs when the SDK client is first created. After initialization, the SDK maintains a persistent connection in streaming mode or periodically polls in polling mode to receive updates to flag rules.

Fallback/Default Values

Fallback values, also called default values, are the values your application provides to the SDK when calling variation() or variationDetail(). These values are returned by the SDK when:

  • The SDK has not yet initialized
  • The SDK cannot connect to LaunchDarkly's service
  • A flag does not exist or has been deleted
  • The SDK is in offline mode

Fallback values are defined in your application code and represent the safe, default behavior your application should exhibit when flag data is unavailable. These values ensure your application continues to function even when LaunchDarkly's service is unreachable.

Critical principle: Every flag evaluation must provide a fallback value that represents a safe, degraded state for your application. Never assume flag data is always available.

Key Metrics

Understanding these metrics helps you measure and improve the resilience of your LaunchDarkly integration.

Initialization Availability

Initialization Availability measures the period where an SDK is able to successfully retrieve at worst stale flags.

High initialization availability means your application will rarely see fallback values served.

Low initialization availability means your application frequently starts without flag data and must rely entirely on fallback values, potentially leading to degraded functionality.

Initialization Latency

Initialization Latency measures the time between creating an SDK client instance and when it successfully retrieves flag rules and is ready to evaluate flags.

This metric is critical for:

  • Application startup time - Long initialization latency can delay application readiness
  • User experience - Client-side applications may show incorrect UI if initialization takes too long
  • Serverless cold starts - High latency can impact function execution time

Best practices aim to minimize initialization latency through:

  • Non-blocking initialization with appropriate timeouts
  • Bootstrapping strategies for client-side SDKs
  • Relay Proxy deployment for serverless and high-scale environments

Evaluation Latency

Evaluation Latency measures the time it takes for the SDK to evaluate a flag and return a value after variation() is called.

This metric is typically very low, under 1ms, because:

  • Flag rules are cached in memory after initialization
  • Evaluation is a local computation that does not require network calls
  • The SDK uses efficient in-memory data structures

Evaluation latency can increase if:

  • The SDK is evaluating many flags simultaneously under high load
  • Flag rules are extremely complex with many targeting rules or large segments
  • The SDK is using external stores like Redis that introduce network latency

Update Propagation Latency

Update Propagation Latency measures the time between when a flag change is made in the LaunchDarkly UI and when that change is reflected in SDK evaluations.

This metric is important for:

  • Real-time feature rollouts - Understanding how quickly changes reach your applications
  • Emergency rollbacks - Knowing how quickly you can disable a feature across all instances
  • Consistency requirements - Ensuring multiple services see flag changes at roughly the same time

Update propagation latency depends on:

  • SDK mode - Streaming mode provides near-instant updates typically under 200ms, while polling mode adds delay based on polling interval
  • Network conditions - Latency between your infrastructure and LaunchDarkly's service
  • Relay Proxy configuration - Additional hop when using Relay Proxy, usually minimal
  • Geographic distribution - Applications in different regions may receive updates at slightly different times

In streaming mode, updates typically propagate in under 200ms. In polling mode, updates propagate within the configured polling interval, typically 30-60 seconds.