A toggle is a switch that can only be in one of two states, on or off. It’s a common word, used for things like the button on your keyboard that turns Caps Lock and Num Lock on or off, or the way you video chat with two people at once with toggled screens. A toggle is also a piece of software architecture that allows for the dynamic re-configuration of service instances.

There are a few different ways to manage toggle configuration. The simplest is to simply hard code toggle settings into source files. This is easy to do and can be useful at smaller scales where the ability to quickly and reliably change a toggle’s state isn’t needed. However, this method is problematic at larger scales and when you have a requirement to test your releases with all flags flipped On (to allow for testing of future behavior).

Another option is to use a configuration system that allows for the dynamic in-memory re-configuration of services. This is a more sophisticated approach that can be very useful but it does come with a cost. It’s important to consider this tradeoff when evaluating your options and picking the right toggle management approach for you.

Many teams will utilize a combination of these techniques to manage their feature flag inventory. Savvy teams will seek to keep this inventory as low as possible as it comes with a carrying cost and can slow down your CI/CD pipeline. Additionally, they will be proactive about removing toggles once they’re no longer required. This can be as simple as adding a task to the team backlog every time a new toggle is introduced or more complex such as creating “expiration dates” on toggles that will fail tests (or even refuse to start an application!) when they reach their expiration.