Feature Flags and Test-Driven Design: Some Practical Tips

A country road with a fork going off to one side, symbolic of a feature flag in codeIn 2018, our team spent a lot of time working with feature flags and test-driven design (TDD).

Our project was to effect an architectural change to our system, changing the source of truth of some data, moving it out of the database owned by a legacy monolith into a new database controlled by a new microservice. However, much of the code requiring the data would remain in the monolith.*

Some examples of the types of things we feature-flagged are:

    • whether to go down a refactored code path or not;
    • whether to publish messages to a message queue when a certain event occurred;
    • how to publish those messages (we tried multiple variations of batching and transaction boundaries to achieve acceptable performance);
    • whether to just delete messages at the receiving end or actually handle them; and
    • whether to use a local source of data or remote one.

We were working on a pretty important piece of code; the kind of business function where, if we stuffed it up, someone would probably have to spend several days doing remedial fixups or making phone calls to chase up millions of dollars. Continue reading