Feature Flags in Fusion: Minimal Design and Trust Boundaries

Problem and takeaway

Fusion services often need to change behavior—enable a new code path, throttle an experiment, or disable a failing integration—without a full redeploy. A feature flag system solves this, but if the flag store is unreachable or misconfigured, it can take down every service that depends on it.

The useful takeaway: treat flags as configuration, not as a runtime dependency for request processing. The smallest safe design uses a read-only client library, a centralized key-value store accessed only by authenticated services, and safe defaults when the store is unavailable.

Version assumption

This note assumes a Fusion runtime that can load an in-process client library and make outbound HTTPS calls. Specific API paths and client behavior vary by Fusion version; adapt the examples to your deployment.

Requirements

• Services can read flag values without blocking user requests.
• Flag changes propagate within an acceptable window, for example seconds rather than minutes.
• Unauthorized services cannot write or modify flags.
• When the flag store is down, services continue with a defined default value.

Smallest suitable design

Use a centralized key-value store, such as Redis or an embedded database, as the flag store. Expose it through a simple REST or gRPC API with a versioned schema. Each Fusion service runs a lightweight client library that:

1. Loads flags at startup.
2. Polls or subscribes for updates.
3. Caches values in memory.
4. Returns a configured default if the store is unreachable.

Example client configuration. Adapt placeholder values to your environment.

fusion_flags:
  store_url: "https://flag-store.internal.example.com/v1"
  token_env: "FUSION_FLAG_TOKEN"
  poll_interval_seconds: 15
  default_on_store_unavailable: false
  flags:
    - name: "new_checkout_flow"
      default: false

Where to run: the client library initializes inside each Fusion service instance on the application host. The flag store runs on a dedicated control-plane host or cluster, not on the same instances serving user traffic.

Required permissions: the service account presenting FUSION_FLAG_TOKEN must have read-only access to the flag store. Write access should be limited to a separate deployment or administrative client.

Trust and data boundaries

The flag store is a trust boundary. Only authenticated, authorized services may read it; only a narrowly scoped admin client may write to it. Client components are read-only and should verify the store's integrity, such as checking TLS certificates, before applying flag changes.

Data boundary: flags are service configuration, not user data. Do not store user identifiers, personal data, or secrets in flag values. If a flag controls access to a sensitive feature, evaluate the flag in the service layer after authentication; never rely on the flag itself as an authorization decision.

Operational checks

• Health probe: the client library reports the flag store as healthy only after a successful read at startup and within the last poll interval.
• Latency metric: track flag lookup time. A sustained value above 100 ms under peak traffic indicates the store or client cache is overloaded.
• Propagation check: after toggling a flag, confirm that a representative sample of service instances reflect the new value within the expected window.

Diagnostic command example. Run from an administrative host with network access to the store.

curl -s -H "Authorization: Bearer $FUSION_FLAG_ADMIN_TOKEN" \
  "https://flag-store.internal.example.com/v1/flags/new_checkout_flow"

Expected check: HTTP 200 with a JSON object containing the flag value, a version, and a timestamp. A 401 or 403 means the admin token lacks permission; a timeout means the store or network path is unhealthy.

Risk: never place admin tokens in application logs or shell history. Inject FUSION_FLAG_ADMIN_TOKEN from a secrets manager at runtime.

Failure modes

Failure	Effect	Response
Flag store unavailable	Clients fall back to defaults; new flag values do not propagate.	Alert on health probe failure; restore the store from a replica or restart it.
Network partition	Some instances see stale flags; others use defaults.	Accept temporary inconsistency; verify convergence after the partition heals.
Misconfiguration disabling all features	User-facing features turn off across services.	Reverse the flag value through the admin client; restart affected services if cached values persist.
Excessive flag change frequency	Store overload and elevated lookup latency.	Rate-limit writes; move high-frequency toggles to a separate fast path.

Rollback

Because toggling a flag changes runtime state, rollback means reversing the flag value through the same admin API used to set it. If clients cache values aggressively, restart the affected Fusion service instances to force a reload, or wait for the poll interval to expire.

Conditions that would change the design

• High-traffic services making flag lookups on every request: add an in-process cache with a short TTL, or a local sidecar proxy, to reduce store load.
• Multi-region deployment: replicate the flag store with eventual consistency; accept that flags may differ by region for a short window.
• Flags that must change mid-request without client polling: switch to a push model, such as a gRPC stream or webhook, instead of polling.
• Strict compliance requiring audit of every flag change: add an immutable append-only log to the flag store.

Limitations and verification

This design assumes the Fusion service can run a client library and reach the flag store over the network. It does not cover client-side feature flags evaluated in a browser or mobile app; those require a separate token-scoped endpoint.

Practical check: deploy the client library to one non-production service instance, toggle a flag through the admin API, and confirm the instance adopts the new value within the configured poll interval without restarting. Then stop the flag store and confirm the service continues serving traffic using the default value.

The research notes that access control, single points of failure, and write frequency require current verification in your environment. Treat the example configuration and command as untested placeholders until validated against your Fusion version and infrastructure.