In the first article of this series we discussed the general concept behind Feature Gating, now we will talk a little about how we can store the flags.

A very naive approach is using a simple file per environment. You can serialize your flags in any way you want, json, xml, ini… then all you have to do is reading this configuration during the application startup and you’re done. 
It’s a very simple method and works very well for small applications and prototypes. Of course you have to remember to deploy the configuration every time something changes. Also you’ll have to implement some sort of flags hot-reloading in the application, otherwise the only option is restarting it (or if you’re under IIS, waiting for app pool recycling).
I said “one file per environment” because I’m pretty sure you have different configurations on DEV, UAT and production. Maybe you want all your flags to be on on DEV and only a small subset on production. Whatever suits your needs.

The next obvious step is persisting the flags in the application database. You can start with a simple table with the flag name and the boolean value.
Later on it will be possible to extend the system by creating relationships to the other tables according to your specific business logic. For example you might want to link flags to user profiles/permissions to allow only subsets of user accessing the features. 
This approach gives more flexibility during deployment, although you still need the hot-reloading. Also, linking the flags table to others might create unnecessary clutter and prevent splitting the monolith.

Let’s move forward to another approach: a key/value storage. Redis can be a very good candidate but here’s a list, just in case. 
Using this kind of databases you have few nice advantages: first of all you can decouple the feature gating from your application using a microservice.
Also, it would be possible to easily store different types of data not just boolean flags. Suppose for example that you want a feature to be enabled only for users in Canada and Japan. A solution could be storing the country codes in the flag value instead of true/false.

The last step is using a third party service. That means you’ll have to write the integration but most of the times there will be libraries already. Just make sure to pick a product with good documentation and decent user base.
Of course you won’t have anymore control over your data and in the worst case you might have to “bend” a little the system to accommodate your application needs. It’s something that happens every time an external solution is used: might cover 90% of the functionalities you need…but that 10% could require a lot of refactoring on your side.

In the next article I’ll show some design patterns you can use in your code to check the feature gates. Stay tuned!

Did you like this post? Then