Feature Flags for Progressive Delivery: Safe Release Without Redeployment

Deployment is not the same as release

I often deploy code with a capability disabled.

deploy binary to 100%
feature enabled to 0%

Then release:

internal users
 -> 5%
 -> 25%
 -> selected customers
 -> 100%

without rebuilding the application.

This separates infrastructure risk from business-feature risk.

Simple server-side flag

if (
  await flags.isEnabled(
    'new-booking-pricing',
    {
      userId,
      tenantId,
      country,
    },
  )
) {
  return newPricing.calculate(request);
}

return legacyPricing.calculate(request);

The evaluation should be server-side for protected business behavior. A browser flag must never become authorization.

Deterministic percentage targeting

function bucket(
  subjectId: string,
  flagKey: string,
): number {
  const hash =
    sha256(`${flagKey}:${subjectId}`);

  return parseInt(
    hash.slice(0, 8),
    16,
  ) % 100;
}

const enabled =
  bucket(userId, flagKey) < 10;

The same user remains in the same cohort.

Kill switch

Some flags are operational:

disable supplier A
disable expensive recommendation
disable live bidding websocket
switch payment provider

I treat kill switches as production controls with audit and access restrictions.

Failure-safe evaluation

What if the flag service is unavailable?

For each flag I define:

default false
default true
cached last known

A safety-sensitive feature normally fails closed.

An availability feature may use cached last-known state.

Database changes

Feature flags do not solve incompatible schema.

If disabled code deploys with a new column:

add nullable column first
deploy code
enable feature gradually
backfill
make constraint later

The DB must support both paths while the flag is mixed.

Flag debt

A temporary release flag should be removed.

I record:

owner
created date
purpose
expected removal date

Otherwise five years later the code contains:

if (oldFeatureFlag) ...
else if (newerFeatureFlag) ...

with nobody knowing which path is used.

Production checklist

• Server-side for business/security logic.
• Deterministic cohorts.
• Define default on evaluator failure.
• Audit flag changes.
• Restrict production access.
• Monitor behavior by flag cohort.
• Keep DB compatible with both paths.
• Add kill switch where operationally useful.
• Assign owner.
• Remove stale flags.

FAQ

Feature flag vs canary?

Canary usually routes versions. Feature flags route behavior inside a deployed version. They are frequently used together.

Can a feature flag replace authorization?

Never.

Should flags live in ConfigMap?

Static operational toggles can, but real progressive targeting often needs a dedicated flag service or database with audit and low-latency evaluation.

Related architecture guides

• Rolling Deployment

• CI/CD Promotion Pipeline

  Architect's final take

  Feature flags let me deploy safely and release deliberately. The discipline is knowing which flags are temporary and removing them after the rollout.