1. Feature Flags

Feature flags serve as temporary toggles for controlled rollouts and experimentation. They’re the foundation of progressive delivery and A/B testing strategies.

Common characteristics:

• Lifecycle: Often temporary, removed after full rollout
• Implementation: Can be modified without deployment
• Purpose: Control feature availability and experimentation
• Scope: Specific features or user segments

Consider this example of feature flag configuration:

{
  "flags": {
    "new-checkout": {
      "name": "New Checkout Experience",
      "enabled": true,
      "rollout": {
        "percentage": 25
      }
    }
  }
}

The corresponding application code remains focused on the feature itself:

if (featureFlags.isEnabled('new-checkout')) {
  return <NewCheckoutFlow />;
} else {
  return <CurrentCheckoutFlow />;
}

While feature flags handle the “what” of feature delivery, they often need to work alongside other controls that manage the “who” and “why” of feature access.

2. Role-Based Access Control (RBAC)

RBAC complements feature flags by providing a security layer that controls user permissions based on roles. While feature flags determine if a feature is available, RBAC determines who can access it.

Common characteristics:

• Lifecycle: Permanent part of system architecture
• Implementation: Defined in security configuration
• Purpose: Control access based on user roles
• Scope: System-wide permissions and actions

// Example of role-based permissions
interface Role {
  name: string
  permissions: string[]
  inheritsFrom?: Role[] // Simplified inheritance example
}
 
const adminRole: Role = {
  name: 'admin',
  permissions: ['manage.users', 'view.analytics'],
  inheritsFrom: [editorRole],
}
 
// Permission check with inheritance
if (rbac.can(user, 'manage.users')) {
  showUserManagement()
}

3. Entitlements

Entitlements complete the control trinity by handling access based on business rules like subscription levels or purchases. They bridge the gap between technical controls and business requirements.

Common characteristics:

• Lifecycle: Follows business model lifecycle
• Implementation: Tied to subscription/billing systems
• Purpose: Control access based on business rules
• Scope: Product features and usage limits

Here’s how entitlements might be configured:

{
  "features": {
    "advanced-analytics": {
      "name": "Advanced Analytics",
      "requiredTier": "pro",
      "limits": {
        "queries-per-day": 1000,
        "data-retention-days": 90
      }
    }
  }
}

And how they’re checked in the application code:

if (await entitlements.can(user, 'advanced-analytics')) {
  return <AdvancedAnalytics />;
} else {
  return <BasicAnalytics />;
}

Bringing It All Together

These three types of controls work together to create a comprehensive feature management system. Here’s how they compare and complement each other:

Understanding how these controls work together is crucial for implementing an effective feature management strategy. Let’s look at how they can be integrated:

// Example of combining different controls
async function canAccessFeature(
  user: User,
  feature: string,
  context: Context,
): Promise<boolean> {
  // Check if the feature is available
  const isFeatureEnabled = await featureFlags.isEnabled(feature, context)
  if (!isFeatureEnabled) return false
 
  // Check user permissions
  const hasPermission = await rbac.can(user, `access.${feature}`)
  if (!hasPermission) return false
 
  // Check subscription status
  const hasEntitlement = await entitlements.check(user, feature)
  return hasEntitlement
}
 
// Usage example
if (await canAccessFeature(user, 'advanced-analytics', context)) {
  showAdvancedAnalytics()
}

As your feature management system grows, you’ll likely encounter several common challenges. Let’s explore these challenges and their solutions.

1. Flag Lifecycle and Cleanup

While best practices suggest keeping feature flags temporary and minimal, real-world development often presents more complex scenarios. It’s easy to add flags, but teams frequently face challenges with their ongoing management.

Let me share a typical story of how feature flag complexity grows over time (one that definitely isn’t based on personal experience… 😅):

// Initial implementation
if (featureFlags.isEnabled('new-checkout-flow')) {
  return <NewCheckout />;
} else {
  return <LegacyCheckout />;
}
 
// Several months later...
if (featureFlags.isEnabled('new-checkout-flow')) {
  if (featureFlags.isEnabled('payment-provider-switch')) {
    return <NewCheckoutWithNewPayment />;
  }
  return <NewCheckout />;
} else {
  // ⁉️ Is this still needed?
  // 🤔 Nobody remembers and everyone's too afraid to remove it
  return <LegacyCheckout />;
}
 
// 1 year later...
if (featureFlags.isEnabled('new-checkout-flow')) {
  // 🤯 Now we have multiple payment providers
  if (featureFlags.isEnabled('payment-provider-switch')) {
    if (featureFlags.isEnabled('stripe-integration')) {
      // 🔍 Which features are actually being used?
      if (featureFlags.isEnabled('stripe-3ds')) {
        return <NewCheckoutWithStripe3DS />;
      }
      return <NewCheckoutWithStripe />;
    } else if (featureFlags.isEnabled('paypal-integration')) {
      // 📝 Documentation? What documentation?
      return <NewCheckoutWithPayPal />;
    }
    // 🤔 Wait, what happens if neither flag is enabled?
    return <NewCheckoutWithNewPayment />;
  }
  // 🚧 TODO: Remove this after migration (added 6 months ago)
  if (featureFlags.isEnabled('legacy-payment-adapter')) {
    return <NewCheckoutWithLegacyAdapter />;
  }
  return <NewCheckout />;
} else {
  // 👻 This code path hasn't been tested in months
  // 💭 Does anyone still use this?
  return <LegacyCheckout />;
}
 
// 2 years later...
// 🙈 We don't talk about what this grew into

This accumulation of flags can lead to several challenges:

• Legacy flags: Flags intended to be temporary that persist in the codebase
• Testing complexity: Multiple flag combinations increase testing requirements
• Maintenance burden: Each flag increases system complexity
• Documentation drift: Configuration and documentation can become outdated
• Partial deployments: Features may remain in transition states

To address these challenges, consider implementing systematic solutions:

Define Clear Lifecycle Policies: Establishing explicit rules for flag lifespans helps maintain codebase health. Feature flags can be tagged with metadata including an owner, expiration date, and intended purpose. A CI pipeline could automatically raise alerts when flags exceed their planned lifespan, prompting cleanup discussions during sprint planning. For instance, temporary flags for A/B tests might have 30-day lifespans, while migration flags could extend to 90 days.

Implement Usage Monitoring: Setting up telemetry systems reveals which flags are actually being evaluated in production. Tools like OpenTelemetry enable logging flag evaluations and powering dashboards showing usage patterns. The resulting insights often surprise teams - like discovering “temporary” flags still being called thousands of times per day months after their intended removal date. This data naturally drives cleanup prioritization and performance optimization efforts.

Automate Compliance Checks: Building guardrails into your CI/CD pipeline helps enforce flag hygiene. A pre-commit hook might require all new feature flags to include metadata like expiration dates and owners. Static analysis tools can detect nested flag conditions (like our example above) and fail builds if flags are nested more than two levels deep without explicit justification.

Establish Clear Ownership: Creating a robust process for flag ownership drives accountability and maintenance. Many teams benefit from treating feature flags as a form of technical debt and scheduling regular cleanup efforts. A simple document tracking all active flags, their owners, and current status provides visibility. Regular feature flag reviews where owners justify keeping any flag older than 90 days help maintain a clean codebase.

Document Flag Dependencies: Maintaining clear documentation of flag interactions prevents unexpected issues during cleanup. Tools like Mermaid.js help create visual diagrams in your codebase, while automated tooling can generate dependency graphs between feature flags. This visibility makes it easier to understand the impact of removing or changing flags, especially when dealing with complex interdependent flags like those controlling checkout flows.

2. Performance Considerations

Performance becomes particularly critical as your feature flag system grows. Imagine a dashboard page that loads several widgets, each needing to check if they should display a new or legacy version. If each widget makes its own feature flag check, you might quickly learn that 429 Too Many Requests isn’t just a theoretical HTTP status code 🫠

Centralize Flag Fetching: A common optimization involves organizing flag fetching at higher levels in your application and passing values down to child components. For example, a page-level component could fetch all required flags during initialization and pass them through React context or props to its children. This approach can significantly reduce the number of network requests and improve page load times.

Implement Batch Evaluations: One effective strategy involves fetching all needed flags for a page or component at once rather than making individual requests. Most feature flag platforms support batch operations that can evaluate multiple flags in a single network request. This is particularly important for applications with complex UIs where many components might need feature flag data simultaneously.

Design Smart Caching Strategies: The implementation of appropriate caching mechanisms requires careful consideration of invalidation needs. A local cache could store flag values with configurable TTLs based on how frequently they change. For example, A/B test flags might need frequent refreshes, while long-term feature rollout flags could be cached longer. Remember to implement proper cache invalidation when flags are updated.

Monitor Performance Impact: Tracking flag evaluation latency and implementing circuit breakers or fallbacks helps maintain application reliability. Tools like browser performance APIs can help measure the impact of feature flag checks on your application’s performance. If flag evaluation starts taking too long or failing, having fallback values ensures your application remains functional. You might default new features to ‘off’ or fall back to cached values when the feature flag service is unavailable.

3. Balancing Separation of Concerns

While we discussed the different types of controls earlier, implementing them in practice requires careful consideration of how they interact. Teams sometimes blur the lines between feature flags, permissions, and entitlements, leading to maintenance challenges.

Here’s how this anti-pattern often appears:

// ❌ Anti-pattern: Mixed concerns
if (
  featureFlags.isEnabled('admin-dashboard') &&
  user.role === 'admin' &&
  user.subscription === 'premium'
) {
  return <AdminDashboard />;
}
 
// ✅ Better: Clean separation of concerns
// First, check if user has access to the admin dashboard
const canAccessAdmin = await accessControl.check({
  feature: 'admin-dashboard',
  user,
  requiredRole: 'admin',
  requiredTier: 'premium'
});
 
if (!canAccessAdmin) {
  return <AccessDenied />;
}
 
// Then, handle UI variations with feature flags
const shouldUseNewUI = featureFlags.isEnabled('new-admin-ui');
return shouldUseNewUI ? <NewAdminDashboard /> : <AdminDashboard />;

This separation helps:

• Maintain clear business logic
• Simplify testing and debugging
• Make code more maintainable
• Support clearer access control policies

On Feature Flag Lifespan

The idea that “feature flags should be temporary” deserves a more nuanced examination:

• Long-lived flags often serve valid architectural purposes, acting as configuration points that enable operational flexibility
• The distinction between “feature flags” and “system configuration” is sometimes artificial
• The cost of removing flags (testing, deployment, coordination) can outweigh their maintenance burden

On Pragmatic Integration

While we’ve emphasized separation of concerns, real-world implementations often require more practical approaches:

// A pragmatic approach with an aggregation layer
class TeamsService {
  async getTeamsAccess(params: { user: User; feature: string; context: Context }) {
    // Encapsulated concurrent execution
    const [flags, permissions, entitlements] = await Promise.all([
      this.featureFlags.isEnabled(params.feature),
      this.rbac.can(params.user, `access.${params.feature}`),
      this.entitlements.check(params.user, params.feature)
    ]);
 
    // Clean interface that handles complexity internally
    return {
      canAccess: flags && permissions && entitlements.hasAccess,
      limit: entitlements.limit,
      renderFallback: () => this.getFallbackUI({ flags, permissions, entitlements })
    };
  }
}
 
// Simple component usage
async function TeamsFeature() {
  const teams = await teamService.getTeamsAccess({
    user,
    feature: 'teams',
    context
  });
 
  if (!teams.canAccess) return teams.renderFallback();
  return <TeamsUI maxTeams={teams.limit} />;
}

This example shows different approaches to managing multiple concerns. While putting all checks directly in the component can lead to performance and maintenance issues, we can maintain clean separation of concerns through a well-designed aggregation layer. This gives us the best of both worlds: clean architecture in our services with pragmatic usage in our components.

On Performance Optimization

The performance optimizations we discussed earlier come with their own tradeoffs. For example:

class FeatureProvider {
  private cache = new Map<string, CacheEntry>()
 
  async getFeatures(context: Context): Promise<FeatureSet> {
    // Centralized fetching seems clean, but...
    try {
      const features = await this.fetchAllFeatures(context)
 
      // ❓ What if only some features fail to fetch?
      // ❓ What if some features need different refresh rates?
      // ❓ What if different components need different contexts?
 
      return features
    } catch (error) {
      // Do we fall back to cache? Partial results?
      // How do we handle cache staleness?
      return this.handleError(error)
    }
  }
 
  // A slightly more nuanced approach might be better
  async getFeaturesByComponent(
    component: string,
    context: Context,
  ): Promise<FeatureSet> {
    // Allow components to manage their own feature states
    // Accept some duplication for better reliability
    const features = await this.fetchFeatures(component, context)
    return this.mergeCachedFeatures(features, component)
  }
}

These examples demonstrate that real-world implementations often require more nuanced approaches than general best practices might suggest. The key is understanding your specific requirements and constraints.