Um punhado de flags é fácil de acompanhar de cabeça: todo mundo no time sabe mais ou menos o que cada uma faz, quem é dono, e se dá pra remover com segurança. Isso deixa de ser verdade bem antes de chegar a cem flags, geralmente em torno de 50, que é onde a maioria dos padrões abaixo começa a quebrar de forma visível.
1. Um limite só, copiado à mão em cada rollout
Se o limite do seu guardrail de latência ou taxa de erro vive como um número literal digitado em cada rollout novo, recalibrar significa achar cada lugar onde foi copiado. É exatamente pra isso que existem os templates de guardrail: defina o formato da política uma vez por projeto, instale em qualquer rollout, e uma recalibração vira uma edição única em vez de uma auditoria.
2. Nenhum dono registrado em lugar nenhum além da memória do time
Uma flag sem dono registrado é tranquila até a pessoa que a criou trocar de time. Em escala pequena, "perguntar por aí" funciona. Depois de 50 flags, não funciona mais. Alguém eventualmente precisa decidir se uma flag sem dono claro é segura de apagar, e "ninguém lembra" não é uma resposta que sobrevive a uma revisão de incidente.
3. Regras de targeting re-derivadas por flag em vez de compartilhadas
Se o mesmo segmento ("usuários internos", "tráfego da região UE", "clientes do plano Enterprise") é reexpresso como uma regra de targeting nova em cada flag que precisa dele, uma mudança no que esse segmento significa (um domínio interno novo, um plano renomeado) exige atualizar cada flag individualmente. Um segmento reutilizável, definido uma vez e referenciado por toda regra que precisa dele, transforma isso numa edição única.
4. Nenhuma distinção entre uma flag permanente e uma temporária
Uma flag de rollout (lançar essa funcionalidade aos poucos, depois remover a flag) e uma flag operacional permanente (kill switch, gate de entitlement) têm ciclos de vida diferentes, mas em escala pequena costumam viver na mesma lista indiferenciada. Depois de 50 flags, essa lista fica impossível de escanear. Você não consegue saber de relance quais flags são resquício de rollout que já deveria ter sido apagado meses atrás.
5. Remoção de flag não tem gatilho nenhum
Nada numa feature flag naturalmente provoca a própria remoção quando o rollout termina. Sem um hábito explícito (uma revisão ao chegar em 100%, um painel de flags que ficaram em 100% por N semanas), as flags se acumulam indefinidamente, e os cinco padrões acima compõem mais rápido quanto mais essa lista cresce.
Nenhum desses é um problema exótico. São o formato comum do que acontece quando uma prática que funcionava pra dez flags é esticada, sem mudar nada, pra duzentas.