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

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 →