A toggle is a switch that has two positions, like the on/off button on your keyboard or the light switches in your house. You can also use the word to describe switching between two activities, like the way you toggle back and forth between screens as you video chat with two friends at once.
The word toggle is a combination of two Latin phrases,
In software development, a toggle (also called a feature flag) is a switch that can be flipped on or off, and which determines the behavior of a program. Typically, it is set to an off position by default and can be turned on by a developer or product owner.
A common approach to implementing a toggle is to hardcode it in code using a preprocessor’s #ifdef feature. However, this is a cumbersome approach once you start to scale because it requires that you re-deploy a code artifact in order to change the toggle configuration. This slows down validation and creates a significant bottleneck in the feedback loop that is so vital to CI/CD.
For this reason, many teams choose to implement a toggle system that allows them to dynamically re-configure the state of a toggle at runtime, without having to re-deploy a change. This may be as simple as exposing an endpoint that allows for in-memory re-configuration of a toggle, or it might involve more sophisticated approaches such as a distributed configuration system or existing application DB. Whatever the approach, it is generally best to keep toggles in production as short-lived as possible. Savvy teams tend to view them as inventory that comes with a carrying cost and seek to remove them once they’re no longer needed. Some even go as far as putting “expiration dates” on their toggles. This helps them manage their feature flag inventory and prevents unused features from lingering in production too long.