when-feature-flags.md

When should I not use feature flags?

Feature flags work great for use-cases that require these properties:

Dynamic

• Feature flag changes are propagated to SDKs in under 200ms without restarting the application

Contextual

• Feature flag rules are evaluated against the user object, allowing you to define rules that easily adapt your business requirements as they change

Time-bound

• Feature flag rules and targets can be made to automatically expire or change using workflows

Delegated

• Approvals, Triggers, and the API allow you to easily delegate the authority to change application behavior to people and services with a complete audit trail

You should not use feature flags:

• As a replacement for secrets management or to target on secrets/credentials
• As a replacement for configuration management
  • Feature flags are not a good fit for replacing configuration that is static or rarely changes at runtime. You may want to consider augmenting / overriding with feature flags instead.
  • Feature flags should not replace any configuration that would completely block the application from starting (database hostname, api urls, etc)
• As a database or file store
  • Try to keep variations small
  • Avoid large/complex JSON payloads if you can. Consider if you can break the dynamic parts out into individual flags
  • Do not bloat the initialization payload by treating feature flags as a source of truth.
• For every commit/sprint/change. Consider the complexity cost of introducing a flag vs the benefits. If your flags look like your commit log or jira backlog, something has gone wrong

  • Good:

    • Release: Chatbox
    • Release: Chatbox Frontend
    • Release: Chatbox Backend

  • Bad:

    • Release: Chatbox Frontend Sprint Fix CSS Bug 112