Architecture 1

Once feature flags appear across many applications, the architecture needs more than a vendor dashboard. It needs clear boundaries between application code, the feature control plane, software delivery, observability and governance.

Separate the application contract from the control plane

Applications
   │
   ├─ frontend
   ├─ backend
   ├─ serverless
   └─ mobile
        │
        ▼
application feature API
        │
        ▼
provider or SDK boundary
        │
        ▼
feature management control plane

Where provider support is mature, OpenFeature can serve as the application facing contract. The control plane may still be Datadog, LaunchDarkly, Harness, Unleash or another approved system.

Keep delivery and runtime control distinct

Source control and CI/CD answer how code reaches an environment. Feature management answers which behavior deployed code exposes.

Git platform and CI/CD
        ↓
deployed application
        ↓
feature evaluation
        ↓
runtime behavior

The same vendor may provide both capabilities, but the architectural responsibilities remain different.

Connect runtime control to observability

A rollout should be observable by variation. Error rate, latency, logs, traces, user sessions and business outcomes should be attributable to the feature state where appropriate.

This is what turns feature flags from a release switch into a controlled feedback loop.

Centralize standards, decentralize ownership

The platform or architecture team should define approved SDKs, identity fields, environment rules, security requirements, naming, audit expectations, emergency procedures and cleanup standards.

Application teams should normally own their flags and release decisions within those guardrails.

Plan for failure

The reference architecture should document:

  • local versus remote evaluation
  • cached configuration behavior
  • startup defaults
  • control plane outage behavior
  • configuration propagation objectives
  • emergency kill switch behavior
  • regional and network failure considerations

Protect the data plane from the control plane

The feature management platform influences runtime behavior, but ordinary application availability should not depend on a successful network call to that platform for every request.

FEATURE CONTROL PLANE
configuration and policy
        │
        ▼
distribution / SDK cache
        │
────────┼────────────────────
        │
APPLICATION DATA PLANE
local evaluation where possible
        │
        ▼
business request continues

The reference architecture should define how the application behaves when the control plane is slow, unreachable or serving an invalid configuration. Depending on the platform and workload, resilience may use local evaluation, cached configuration, last known good values, schema validation and code level defaults.

Control plane failure must not automatically become application failure.

Security belongs in the reference architecture too

The architecture standard should define production RBAC, environment isolation, audit requirements, approved evaluation context fields and rules for sensitive data. Application teams should know which identity attributes may be sent to the provider rather than treating evaluation context as an unrestricted metadata bag.

For high impact flags, the reference architecture should also support separation of duties and approval workflows without forcing every low risk experiment through the same process.

One control plane is a useful default, not a law

Large enterprises may inherit multiple platforms through acquisitions or existing product teams. The architecture should name one default while supporting controlled exceptions and migrations.

The dangerous design is not having two vendors somewhere in the enterprise. It is letting one application depend on competing control planes without a clear authority model.

A practical reference model

                 DELIVERY
                   │
             Git / CI / CD
                   │
                   ▼
              APPLICATIONS
          frontend backend mobile
             serverless APIs
                   │
              OpenFeature
                   │
               provider
                   │
                   ▼
        FEATURE CONTROL PLANE
                   │
       ┌───────────┼───────────┐
       ▼           ▼           ▼
 governance   observability  experiments
       │           │           │
       └───────────┴───────────┘
                   │
             release decision

The specific products can change. The responsibilities should remain clear.

Feature Flags series

← Feature Flag Governance and Technical Debt   OpenFeature and Vendor Portability →