Como garantir chamadas de APIs em Spring Boot sem risco de chamadas inválidas

Quando trabalhamos com múltiplas configurações de serviços, como chamadas a APIs legadas e novas, é fácil acabar com cenários onde nenhuma das opções é acionada. No meu time, sempre tentamos usar validações cruzadas nas configurações do Spring Boot para evitar isso.

Por exemplo, se temos duas flags de configuração, como employeeEngine.callLegacy e employeeEngine.callNewApi, o ideal é criar uma validação que garanta que ao menos uma delas esteja ativada. Assim, evitamos chamadas vazias ou desnecessárias. A decisão fica mais saudável quando o time consegue medir o impacto depois.

Na prática, podemos fazer uma validação customizada na fase de startup, usando um @PostConstruct ou um ApplicationRunner, que verifica se pelo menos uma dessas flags está true. Caso contrário, lança uma exception ou ajusta automaticamente as configurações. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.

Isso ajuda na segurança, na economia de recursos e evita bugs de lógica que só aparecem em produção. Você já passou por alguma situação onde uma configuração vazia causou problema de deployment ou downtime? Como vocês lidam com validações assim no dia a dia? O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar.