Flagship Docs

Appearance

Flag Evaluation ​

Flagship uses a local evaluation model. This means that when your application checks the value of a feature flag, the decision is made instantly within your application's memory, without making a network request to Flagship's servers.

This architecture ensures that your feature flags are evaluated with zero latency, maximum resiliency, and complete privacy.

How It Works ​

The evaluation process consists of two distinct phases: Synchronization and Evaluation.

1. Synchronization (Server-to-Client) ​

When your application starts (and periodically thereafter), the Flagship SDK connects to our edge network to download the latest Rollout Plans.

A Rollout Plan contains all the logic required to evaluate flags, including:

  • Targeting rules and segments.
  • Percentage rollout configurations.
  • Prerequisite flags.
  • Schedule constraints.

This payload is highly compressed and cached at the edge, ensuring fast initialization. Once the SDK receives this plan, it is stored in memory (and optionally persisted to disk for offline redundancy).

2. Evaluation (Local) ​

When your code calls a method like flagship.get("new-checkout", default_value, dimensions), the SDK evaluates the flag locally against the stored Rollout Plan.

mermaid
graph LR
    A[Application Code] -->|Get Flag| B(Flagship SDK)
    B -->|Check Rules| C{Local Memory}
    C -->|Return Value| A
    style C fill:#f9f,stroke:#333,stroke-width:2px

Because this happens entirely in memory:

  • Speed: Evaluations take microseconds.
  • Reliability: If your network goes down or Flagship's API becomes unreachable, your application continues to evaluate flags using the last known good configuration.

Benefits ​

Resiliency ​

Your application's runtime behavior should never depend on a third-party service's uptime. With local evaluation, once the Rollout Plan is initialized, your application effectively runs in "safe mode" autonomously. Even in a complete network outage, feature flags continue to resolve correctly based on the cached rules.

Privacy ​

Since evaluation happens locally, user data never leaves your infrastructure. Attributes like user_id, email, or custom attributes used for targeting are passed to the SDK function but are processed entirely within your application's process. Flagship never sees your user data; it only sees the metadata of the evaluation (e.g., "Flag X was evaluated 50 times") if you choose to enable telemetry.

Speed at Scale ​

Local evaluation decouples your traffic from our servers. Whether you have 100 users or 100 million, the latency of a flag check remains constant (microseconds). You don't need to worry about rate limits or network latency impacting your user experience.