Uma Secretaria de Fazenda estadual está modernizando sua plataforma de integração tributária. O arquiteto-chefe propôs substituir o barramento de serviços (ESB) centralizado por uma malha de serviços (service mesh) baseada em sidecars, mantendo os mesmos contratos SOAP/WSDL dos serviços legados. Durante a revisão de arquitetura, a equipe levantou quatro preocupações:
- I. A malha de serviços, por operar na camada de transporte (L4) e na camada de aplicação (L7) via proxies sidecar, pode aplicar políticas de resiliência (timeouts, retries, circuit breaking) e mTLS sem alterar o código dos serviços legados, mas não substitui funcionalidades de mediação de mensagens, transformação de payload e roteamento baseado em conteúdo que um ESB tradicional oferece.
- II. A migração para service mesh elimina a necessidade de um registro de serviços (service registry), pois os sidecars descobrem dinamicamente os endpoints por meio do plano de controle, tornando dispensável qualquer mecanismo de descoberta de serviços.
- III. Em um cenário de interoperabilidade entre sistemas heterogêneos, a adoção de service mesh preserva a compatibilidade dos contratos WSDL existentes, pois a malha atua como intermediária transparente, sem exigir a reescrita dos serviços como microsserviços REST.
- IV. O uso de sidecars introduz latência adicional por salto de rede e aumenta o consumo de recursos, o que pode ser mitigado com o padrão de arquitetura de sidecar sem proxy (sidecarless), como eBPF, mas essa alternativa ainda impõe limitações quanto à inspeção de protocolos de aplicação específicos.
Considerando os conceitos de engenharia e arquitetura de software, integração de sistemas e interoperabilidade, quais afirmativas estão corretas?
