Lightweight feature flags that don't need the database
Problem
Our current feature flags are stored in the database and cached per thread.
This is problematic for two reasons:
- Feature flags in hot spots like sidekiq or rack middlewares causing a database call every time a thread starts, adding pressure to the database cluster.
- Code that executes before the database cluster is available, such as changes to Puma configuration or initializers that execute early in the chain, cannot use FFs, and have led to incidents in the past. We often use environment variables to switch these code paths instead, which is a highly manual process and requires close coordination between product and production engineers.
Moreover, in those places being able to scope feature flags to groups or projects often doesn't make sense, so perhaps we should have a way of storing these feature flags in the environment or in memory of the parent process rather than per thread.
Solution
Provide a solution that allows us to switch code and configuration such that:
- The database is not on the critical path
- Developers can act autonomously when rolling these out, just as they do with ordinary FFs