Feature toggles in Microservices - System Design Guide

Problem Statement

Deploying new features directly to production can cause failures or degrade user experience if the feature is not fully ready or has bugs. Without a way to control feature availability dynamically, teams risk impacting all users and complicate rollback processes.

Solution

Feature toggles allow teams to turn features on or off at runtime without deploying new code. This is done by wrapping new functionality in conditional checks that read toggle states from a centralized service or configuration. It enables gradual rollout, quick rollback, and targeted user testing.

Architecture

Client/User

→Microservice

↓

Feature Logic

Feature Logic

This diagram shows a client request reaching a microservice, which queries a feature toggle service to decide if a feature should be enabled before executing the feature logic.

Trade-offs

✓ Pros

→

Enables safe deployment by decoupling feature release from code deployment.

→

Supports gradual rollout to subsets of users for testing and feedback.

→

Allows instant rollback by toggling features off without redeploying.

→

Facilitates A/B testing and experimentation.

✗ Cons

→

Adds complexity to codebase with conditional logic scattered around.

→

Requires robust toggle management to avoid stale or forgotten toggles.

→

Potential performance overhead if toggle checks are frequent and not cached.

Use when deploying features that require controlled rollout, testing in production, or quick rollback capability. Especially valuable in microservices with frequent deployments and multiple teams.

Avoid for very simple applications with infrequent releases or when feature toggles would add unnecessary complexity and maintenance overhead.

Real World Examples

Netflix

Uses feature toggles to gradually roll out new streaming features to subsets of users, minimizing risk and gathering feedback.

Uber

Employs feature toggles to enable or disable features like surge pricing algorithms dynamically without redeploying services.

LinkedIn

Uses feature toggles to test new UI components with select user groups before full release.

Code Example

The before code always applies a discount, which may not be ready. The after code checks a feature toggle before applying the discount, allowing dynamic control without redeployment.

Microservices

### Before (no feature toggle)

def process_payment(user, amount):
    # New feature: apply discount
    discounted_amount = amount * 0.9
    charge_user(user, discounted_amount)


### After (with feature toggle)

FEATURE_TOGGLES = {
    "discount_feature": False
}

def is_feature_enabled(feature_name):
    return FEATURE_TOGGLES.get(feature_name, False)

def process_payment(user, amount):
    if is_feature_enabled("discount_feature"):
        amount = amount * 0.9
    charge_user(user, amount)

Alternatives

Blue-Green Deployment

Deploys two identical environments and switches traffic between them to release features, instead of toggling features at runtime.

Use when: Choose when you want zero downtime deployments and can afford full environment duplication.

Canary Releases

Gradually releases new versions to a small subset of users by routing traffic, rather than toggling features inside the code.

Use when: Choose when you want to test entire new versions or services rather than individual features.

Summary

Feature toggles let teams enable or disable features at runtime without redeploying code.

They help safely roll out, test, and rollback features in microservices environments.

Proper management is needed to avoid complexity and stale toggles.

Practice

1. What is the main purpose of using feature toggles in microservices?

easy

A. To enable or disable features without changing the code

B. To increase the number of microservices in the system

C. To replace the API Gateway functionality

D. To store user data securely

Solution

1. Step 1: Understand feature toggles concept

   Feature toggles allow turning features on or off dynamically without code deployment.

2. Step 2: Compare options with feature toggles purpose

   Only To enable or disable features without changing the code correctly describes this purpose; others are unrelated.

3. Final Answer:

   To enable or disable features without changing the code -> Option A

4. Quick Check:

   Feature toggles = Enable/disable features [OK]

Hint: Feature toggles control features without code changes [OK]

Common Mistakes:

• Confusing feature toggles with service scaling
• Thinking toggles replace API Gateway
• Assuming toggles store user data

2. Which of the following is the correct way to check a feature toggle named newUI in a microservice code snippet?

easy

A. if featureToggle.isActive('newUI') { /* use new UI */ }

B. if featureToggle['newUI'] == true then { /* use new UI */ }

C. if featureToggle.newUI = true { /* use new UI */ }

D. if (featureToggle.isEnabled('newUI')) { /* use new UI */ }

Solution

1. Step 1: Identify correct syntax for feature toggle check

   Common pattern is calling a method like isEnabled('featureName') returning boolean.

2. Step 2: Evaluate each option's syntax

   if (featureToggle.isEnabled('newUI')) { /* use new UI */ } uses correct method and syntax. if featureToggle['newUI'] == true then { /* use new UI */ } mixes syntax styles incorrectly. if featureToggle.newUI = true { /* use new UI */ } uses assignment instead of comparison. if featureToggle.isActive('newUI') { /* use new UI */ } uses a wrong method name.

3. Final Answer:

   if (featureToggle.isEnabled('newUI')) { /* use new UI */ } -> Option D

4. Quick Check:

   Correct method call = if (featureToggle.isEnabled('newUI')) { /* use new UI */ } [OK]

Hint: Look for method isEnabled with feature name string [OK]

Common Mistakes:

• Using assignment '=' instead of comparison
• Mixing syntax from different languages
• Using incorrect method names like isActive

3. Consider this pseudocode for a microservice using feature toggles:

if (featureToggle.isEnabled('betaFeature')) {
  return 'Beta feature active';
} else {
  return 'Beta feature inactive';
}

If the toggle betaFeature is OFF, what will be the output?

medium

A. 'Beta feature active'

B. Error: toggle not found

C. 'Beta feature inactive'

D. No output

Solution

1. Step 1: Understand toggle state effect on code flow

   If betaFeature is OFF, isEnabled returns false, so else branch runs.

2. Step 2: Identify output from else branch

   Else branch returns 'Beta feature inactive'.

3. Final Answer:

   'Beta feature inactive' -> Option C

4. Quick Check:

   Toggle OFF = else output [OK]

Hint: Toggle OFF triggers else branch output [OK]

Common Mistakes:

• Assuming toggle OFF triggers if branch
• Expecting error when toggle is off
• Ignoring else branch output

4. A developer wrote this code snippet to check a feature toggle but it always activates the feature regardless of toggle state:

if (featureToggle.isEnabled = true) {
  enableFeature();
} else {
  disableFeature();
}

What is the main error causing this behavior?

medium

A. Feature toggle name is incorrect

B. Using assignment '=' instead of comparison '==' in the if condition

C. Missing parentheses around the condition

D. Calling the wrong method name for toggle check

Solution

1. Step 1: Analyze the if condition syntax

   The condition uses assignment '=' which sets isEnabled to true, always true.

2. Step 2: Identify correct comparison operator

   It should use '==' or a method call to compare, not assignment.

3. Final Answer:

   Using assignment '=' instead of comparison '==' in the if condition -> Option B

4. Quick Check:

   Assignment in if condition causes always true [OK]

Hint: Check if condition uses '==' not '=' [OK]

Common Mistakes:

• Confusing assignment '=' with equality '=='
• Assuming method name is wrong without checking syntax
• Ignoring parentheses importance

5. In a microservices system, you want to safely roll out a new payment feature using feature toggles. Which design approach best supports gradual rollout and quick rollback?

hard

A. Use a centralized feature toggle service with API Gateway to control toggle states dynamically

B. Hardcode toggle values in each microservice and redeploy to change them

C. Use environment variables set at deployment time to control toggles

D. Deploy separate microservices for old and new features without toggles

Solution

1. Step 1: Identify requirements for gradual rollout and rollback

   We need dynamic control over feature toggles without redeploying services.

2. Step 2: Evaluate design options

   Use a centralized feature toggle service with API Gateway to control toggle states dynamically uses centralized toggle service and API Gateway for dynamic control, ideal for gradual rollout and rollback. Options A and B require redeployment or static config. Deploy separate microservices for old and new features without toggles lacks toggle control.

3. Final Answer:

   Use a centralized feature toggle service with API Gateway to control toggle states dynamically -> Option A

4. Quick Check:

   Central toggle service + API Gateway = safe rollout [OK]

Hint: Central toggle service enables dynamic control [OK]

Common Mistakes:

• Using static toggles requiring redeployment
• Ignoring API Gateway role in toggle management
• Deploying separate services instead of toggling