Feature Toggles: A Simple Way to Manage Access to Premium Features

Imagine building an application with both free and premium features, and wanting to roll out a new feature for premium users without disrupting the experience for everyone else. The challenge is ensuring only the right users get access while keeping things smooth. For example, a streaming service like Netflix offers exclusive content or features to premium users, such as higher streaming quality or early access to new shows. They need a way to release these features gradually to the right audience and monitor performance before full rollout.

This is where feature toggles come in. They allow us to control which features are visible to different user groups, like premium subscribers. By enabling or disabling specific features based on user access levels, we can release new features gradually to the right audience, just like Netflix does. This approach helps monitor the feature’s performance, gather feedback, and ensure everything runs smoothly before making it available to all premium users, without affecting non-premium ones.

Understanding Feature Toggles: More Than Just On/Off Switches

So, what is a feature toggle? A feature toggle, also known as a feature flag, is a technique used in software development to enable or disable specific features without deploying new code. It allows us to control the visibility and availability of certain features in an application based on specific conditions, such as user roles or subscription levels.

It’s much more than a simple if/else statement. Feature toggles provide us with a powerful strategy for managing application behavior. Think of it as a control panel for features, where switches can be flipped on and off based on the needs of different users. This gives us the flexibility to gradually release features, test them, or provide exclusive content to certain user groups—without disrupting the experience for everyone else.

When Is This Useful?

Here are some scenarios where feature toggles really shine:

1. Gradually rolling out a new UI to ensure it doesn’t break anything
2. Running A/B tests to figure out if a blue button performs better than a red one
3. Controlling access to premium features (we’ll dive deeper into this one!)
4. Testing features in different environments without changing the code
5. Giving specific users access to beta-test features while others remain unaware

System Architecture: How It All Fits Together

Let’s take a closer look at how a feature toggle system works. Breaking it down into components helps make it clearer.

The System Components

The feature toggle system consists of several key parts:

1. Client Browser: This is where the user interacts with the application (e.g., web or mobile browser).
2. Frontend App: The client browser communicates with the frontend application, where the user interface is managed.
3. Backend API: The frontend app sends requests to the backend API, which handles the business logic and makes decisions about feature availability.
4. Toggle Service: The toggle service evaluates whether a specific feature should be enabled or disabled based on user access levels and feature configurations.
5. User Service: This service checks user-related information, like their subscription level or role, to determine their access rights.
6. Toggle DB: The database where feature configurations are stored, determining whether a feature is on or off for specific user groups.
7. User DB: The database that stores user information, such as their subscription level or status.

Understanding the Flow

Consider the flowchart that illustrates how the system handles feature access. Here’s what happens step-by-step:

1. The frontend app requests information about feature access from the backend API.
2. The backend API then checks the user’s subscription level (whether they are a premium or free user).
3. If the user is a premium subscriber, the toggle service checks if the requested feature is enabled for their user group by looking at the Toggle DB.
   • If the feature is enabled, the feature is shown to the user.
   • If the feature is disabled, the user is shown an upgrade prompt.
4. If the user is a free subscriber, the backend skips the feature toggle check and directly shows the upgrade prompt.

Premium Feature Access Control: A Real-World Example

Imagine building a SaaS platform with both free and premium features. Just like streaming services such as Netflix, where premium subscribers get access to exclusive content like higher streaming quality or early releases, we need to ensure that only paying users can access these features. The challenge is offering these benefits without affecting the experience of free-tier users.

Netflix, for example, uses feature toggles to gradually release premium features or exclusive content to a select group of premium users. This helps them test the feature, gather feedback, and monitor performance before rolling it out to all paying users. This strategy ensures a smooth user experience while maintaining the value of their subscription plans.

To implement this in our own projects, let’s take a look at how we can set up the necessary data models and backend logic to manage access control based on subscription levels, using feature toggles to control feature availability.

Setting Up the Data Models

@Entity
public class ToggleConfig {
    @Id
    private String featureName;
    private String subscriptionLevel;
    private boolean enabled;
    private Date lastModified;
    private String modifiedBy;

    // Getters and setters
}

ToggleConfig stores the configuration for each feature. The featureName identifies the feature, subscriptionLevel defines which users can access it, and enabled indicates whether it is active for that level. The lastModified and modifiedBy fields help track changes made to the feature.

@Entity
public class User {
    @Id
    private String id;
    private String subscriptionLevel;
    private Date subscriptionStart;
    private Date subscriptionEnd;

    // Getters and setters
}

User stores information about a user, such as their subscriptionLevel, which is essential for checking feature access.

@Entity
public class FeatureAccess {
    @Id
    private String id;
    private String userId;
    private String featureName;
    private boolean hasAccess;
    private Date lastChecked;

    // Getters and setters
}

FeatureAccess records whether a user has access to a particular feature, including the user ID, feature name, access status, and the date it was checked.

The Backend Magic

Here’s where it gets interesting. Let’s look at how we check if a user can access a feature:

@Service
public class FeatureToggleService {
    private final ToggleRepository toggleRepository;
    private final UserRepository userRepository;
    private final FeatureAccessRepository accessRepository;

    public boolean isFeatureEnabledForUser(String userId, String featureName) {
        // Get user subscription level
        User user = userRepository.findById(userId)
            .orElseThrow(() -> new UserNotFoundException(userId));

        // Check feature toggle configuration
        Optional<ToggleConfig> toggleConfig = toggleRepository
            .findByFeatureAndSubscriptionLevel(featureName, user.getSubscriptionLevel());

        // Record access check
        FeatureAccess access = new FeatureAccess();
        access.setUserId(userId);
        access.setFeatureName(featureName);
        access.setHasAccess(toggleConfig.map(ToggleConfig::isEnabled).orElse(false));
        access.setLastChecked(new Date());
        accessRepository.save(access);

        return access.isHasAccess();
    }
}

This service first retrieves the user’s subscription level by querying the UserRepository. Then it checks if the feature is enabled for that subscription by querying the ToggleRepository. After checking, the result is saved in the FeatureAccess repository, and the access status is returned.

@RestController
public class FeatureToggleController {
    private final FeatureToggleService featureToggleService;

    @GetMapping("/api/features/{featureName}/access")
    public ResponseEntity<FeatureAccessResponse> checkFeatureAccess(
        @PathVariable String featureName,
        @RequestParam String userId
    ) {
        boolean hasAccess = featureToggleService.isFeatureEnabledForUser(userId, featureName);

        FeatureAccessResponse response = new FeatureAccessResponse(
            featureName,
            hasAccess,
            hasAccess ? "Feature available" : "Please upgrade to access this feature"
        );

        return ResponseEntity.ok(response);
    }
}

This controller exposes an API endpoint that checks whether a user has access to a specific feature. It calls the FeatureToggleService to perform the necessary checks and returns the result.

Making It Look Good: The Frontend

On the frontend, the idea is to either show the premium feature or an upgrade prompt. Here’s how this is handled in React:

import React, { useEffect, useState } from 'react';
import { useFeatureToggle } from './hooks/useFeatureToggle';

const PremiumFeature = ({ userId, featureName }) => {
  const { isEnabled, isLoading, error } = useFeatureToggle(userId, featureName);

  if (isLoading) return <LoadingSpinner />;
  if (error) return <ErrorMessage error={error} />;

  return (
    <div className="feature-container">
      {isEnabled ? (
        <div className="premium-feature">
          <h2>Premium Feature</h2>
          <PremiumContent />
        </div>
      ) : (
        <div className="upgrade-prompt">
          <h2>Upgrade Required</h2>
          <p>This feature is available for premium subscribers only.</p>
          <UpgradeButton />
        </div>
      )}
    </div>
  );
}

This component checks the feature status using the useFeatureToggle hook. If the feature is enabled, it displays the premium content; if not, it shows an upgrade prompt.

// Custom Hook for Feature Toggle
const useFeatureToggle = (userId, featureName) => {
  const [state, setState] = useState({
    isEnabled: false,
    isLoading: true,
    error: null
  });

  useEffect(() => {
    const checkFeatureAccess = async () => {
      try {
        const response = await fetch(
          `/api/features/${featureName}/access?userId=${userId}`
        );
        const data = await response.json();

        setState({
          isEnabled: data.hasAccess,
          isLoading: false,
          error: null
        });
      } catch (error) {
        setState({
          isEnabled: false,
          isLoading: false,
          error: error.message
        });
      }
    };

    checkFeatureAccess();
  }, [userId, featureName]);

  return state;
};

The custom hook makes an API call to check the feature's availability for the given user and feature name. It manages the state for loading, error, and the feature's enabled status.

Making It Work in the Real World: Best Practices

Now that we’ve seen how everything works, here are some additional technique to make the feature toggle system robust:

1. Performance Matters

• Caching toggle states is crucial since checking the database for every request can be slow.
• Keep the toggle logic efficient and simple to avoid unnecessary delays.
• Use background jobs for logging to keep the user experience smooth.

2. Keep It Secure

• Always validate user permissions to prevent unauthorized access.
• Encrypt sensitive toggle configurations for security.
• Use audit logs to track changes made to feature configurations.

3. Stay Organized

• Regularly monitor which toggles are in use.
• Clean up unused toggles to keep things tidy.
• Document everything to maintain clarity.

4. Think About Scale

• Design the system to scale efficiently for a large user base and numerous toggles.
• Use caching effectively for scalability.
• Consider using a distributed configuration system for global reach.

Wrapping Up

Feature toggles really feel like a superpower in the development world. They help us:

• Gradually release features and test them safely.
• Experiment with new ideas without risking the entire application.
• Provide tailored experiences for different user groups.
• Do all of this without deploying new code each time.

Starting with a single feature toggle is a great way to get familiar with this concept. As the comfort level grows, expanding to more complex scenarios—like controlling premium feature access—becomes easier.

The best part is that once feature toggles are in place, releasing new features becomes far less stressful. Instead of hoping for the best, we have full control over who sees what and when.

Thanks for reading! I’d love to hear your thoughts and experiences with implementing feature toggles. Feel free to share your comments or any insights you have from using them in your own projects.