Feature flags can’t fully replace a hotfix process.
You probably won’t be putting every single change behind a feature flag. That would greatly increase the complexity of the code as well as the management of the state of all of those flags. In addition, some changes can’t easily be put behind feature flags, such as dependency updates and infrastructure changes. You need to balance the complexity of the code, the performance impacts of checking for feature flag status, and the benefit of using and managing the flag.
In some cases, though, feature flags can reduce the need for hotfix branches. Techniques such as feature flags, canary releases, and dark launching can help if you find yourself frequently hotfixing. Dark launching can help find potential performance issues in backend API calls before you display the results of those calls to users in the UI, especially if you have robust monitoring set up on the application and infrastructure. Canary releases roll out changes slowly so that if there is a problem, it affects a small subset of users. You can couple both with feature flags, especially of a more dynamic type that doesn’t require a redeployment, to be able to disable functionality quickly if your monitoring or canary users report problems. By turning off the functionality, you ensure that your system is stable and you can take your time with a fix.
I’m sure that canary releases, dark launching, and feature flags are three of the enablers behind deploying many times in a day. Netflix has a microservice architecture, so deploying new services or very small backward-compatible changes to existing services at an API level can also promote rapid deployments. Generally, though, they probably aren’t cherry-picking code but rather focusing on moving forward and frequently deploying a branch that passes automated testing