ADR-033: Feature flag management — AWS AppConfig¶
| Status | Accepted |
| Date | 2026-04-10 |
| Deciders | CTO, Head of Architecture |
| Affects repos | bank-core, bank-kyc, bank-aml, bank-payments, bank-credit, bank-risk-platform, bank-platform, bank-app |
Status¶
Accepted — 2026-04-10
Context¶
ADR-022 mandates feature flags for trunk-based development — incomplete features are merged to main behind a flag rather than in long-lived branches. A flag evaluation service is required before any repo begins active development. Requirements: near-zero latency impact on Lambda invocations, no always-on infrastructure, per-environment control, and gradual rollout support.
Decision¶
AWS AppConfig is the feature flag service across all repos.
Lambda integration: The AppConfig Lambda extension runs as a sidecar. Flags are cached locally in the execution environment — evaluation is a local hash-map lookup with no network call per invocation. The extension polls AppConfig for updates on a configurable interval (default 45 seconds).
Flag naming convention:
{domain}.{feature}.{variant}
e.g. payments.instant-transfer.enabled
kyc.biometric-fallback.enabled
app.cross-border-wallet.visible
Flags are owned by the domain that owns the feature. No domain evaluates another domain's flags directly — flags surface only at the API or UI layer of the owning domain.
Environment promotion: One AppConfig application per repo, one configuration profile per environment (dev, uat, prod). Flag states are promoted through environments as part of the standard release pipeline — not changed in production directly.
Rollout strategy: AppConfig deployment strategies control rollout pace. Standard pattern: linear 10% → 50% → 100% with automated CloudWatch alarm rollback. A breached alarm at any stage halts and reverts the rollout automatically.
Migration path¶
LaunchDarkly when the product team requires user-segment targeting, A/B experimentation, or per-customer kill switches on live traffic. Flag evaluation is wrapped in a thin abstraction layer in each repo — swapping the underlying service is a single-file change per repo with no flag rename required.
Rejected alternatives¶
| Option | Reason rejected |
|---|---|
| LaunchDarkly | $75–150+/month; seat-based cost; capabilities exceed build-phase requirements |
| Unleash (self-hosted) | Always-on hosting required — conflicts with serverless model |
| SST config / environment variables | No runtime evaluation; no gradual rollout; no per-environment promotion |
| Custom DynamoDB table | Operational burden; no deployment strategy; no rollback; reinventing the wheel |
Consequences¶
Zero baseline cost at launch. Flag evaluation adds no measurable latency (local extension cache). Gradual rollout with automatic rollback reduces deployment risk without custom tooling. Migration to LaunchDarkly is low-friction when product experimentation requirements grow post-launch.
Signoff record¶
| Date | Name | Role | Status |
|---|---|---|---|
| 2026-04-10 | Ross Millen | CTO | Approved |
| 2026-04-10 | Ross Millen | Head of Architecture | Approved |
| 2026-04-10 | Ross Millen | Head of Data | Approved |
Capabilities¶
| Capability | Description | Relationship |
|---|---|---|
| CAP-111 | Feature flag & remote config | enabled — AppConfig is the feature flag service; gradual rollout with auto rollback |
Related decisions¶
| ADR | Title | Relationship |
|---|---|---|
| ADR-022 | CI/CD and deployment strategy | resolves the deferred feature flag tool from ADR-022 |
| ADR-025 | API layer — HTTP API Gateway and SST | Lambda sidecar extension runs within SST Lambda execution model |
All ADRs
Compiled 2026-05-22 from source/entities/adrs/ADR-033.yaml