On building a simple feature flag system

When building a new application you will have the need to selectively enable features. Whether for testing a new feature or controlling access to modules. This is where a feature flag system comes in.

In essence, a feature flag system is a way to associate a unique toggle (flag) with a feature. This simple setup is enough to make a feature available, and to whom.

Common use cases for feature flags:

1. Testing new features with selected users/customers.
2. Disabling a feature that went amok.
3. Making a system feature available to selected customers only.

The basic version

For a basic feature flag system we’ll start with a table where we’ll store the individual feature flags created.

This is a simple table as follows.

CREATE TABLE feature_flags (
    id TEXT NOT NULL,
    name TEXT NOT NULL,
    status TEXT NOT NULL DEFAULT 'ACTIVE',
    createdAt TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updatedAt TIMESTAMP(3) NOT NULL
);

If you use case does not require any granularity to apply the use case, this is all you need to start using feature flags in your application.

However, at this point, we can go further and associate the toggles with either a customer or a specific user or a user role.

Below is an example of a table that allows setting/using feature flags per roles.

-- this could be a features_on_roles or features_on_customers
CREATE TABLE features_on_roles (
    id TEXT NOT NULL,
    feature_flag_id TEXT NOT NULL,
    user_role_id TEXT NOT NULL,
    status TEXT NOT NULL DEFAULT 'ACTIVE',
    createdAt TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updatedAt TIMESTAMP(3) NOT NULL
);

If you would like to associate a feature flag with a specific customer instead of roles, you can either modify the table above, or have another one called features_on_customers that holds the association between the two.

From here, all you need is:

• Create functionality on your backend to manage the flags (CRUD)
• Create functionality on your frontend to check for them. If you are on React land here you’d create hooks or specific components to encapsulate check logic.

Why not a library or service?

The main question you might be asking is “why bother building this instead of using a library/service?”

The argument I am making here is that such functionality is:

1. Simple to implement
2. Simple to maintain
3. Critical for your application
4. Simple to debug
5. Cheap

With these points in mind, I would argue that the pros of implementing instead of buying something ready outweighs the time-saved.

To recap:

For a basic feature flag system you need:

• A table to store all the feature flags
• A table to relate each feature flag to roles, customers, etc
• CRUD methods for handling the records
• Frontend support for checking and reacting to the flags.