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.