Questão de Arquitetura de Software — Sistemas Distribuídos — FGV 2026
Arquitetura de Software›Sistemas Distribuídos
Código
fg133770
Banca
FGV
Órgão
TJ-RJ
Ano
2026
Nível
Superior
Cargo
Analista Judiciário - Tecnologia da Informação - Analista de Infraestrutura de TIC
Uma instituição financeira está redesenhando sua arquitetura de TI, migrando de uma arquitetura monolítica para microsserviços executados em contêineres sobre Kubernetes. Em um segundo momento, alguns componentes pontuais (por exemplo, funções de validação de CPF, cálculo de score ou envio de notificações) foram implementados em modelo serverless (Functions as a Service), disparados sob demanda.Para lidar com a complexidade crescente da comunicação entre microsserviços (observabilidade, tracing, retry, circuit breaking e políticas de segurança mTLS), a equipe está avaliando a adoção de um service mesh (como Istio ou Linkerd).Com base nesse cenário, é correto afirmar que:
Aa adoção de serverless torna desnecessária a arquitetura de microsserviços, pois funções serverless substituem, por definição, serviços implantados em contêineres em qualquer cenário;
Bem uma arquitetura com service mesh, a comunicação entre serviços passa a ocorrer sem uso da rede, por meio de chamadas diretas em memória entre sidecars, eliminando latência e falhas de transporte;
Ca principal função de um service mesh é substituir o orquestrador de contêineres, assumindo responsabilidades de agendamento de pods, distribuição de carga entre nós físicos e detecção de falhas de hardware;
Dmicrosserviços e serverless são abordagens mutuamente excludentes, de forma que uma aplicação que utiliza funções serverless não pode, ao mesmo tempo, empregar serviços em contêineres para o mesmo domínio de negócio;
Eo uso de um service mesh busca externalizar, para a infraestrutura, diversas preocupações transversais, como roteamento de tráfego, telemetria, autenticação mútua (mTLS) e políticas de resiliência, reduzindo a necessidade de implementar essas funcionalidades no código de cada microsserviço.
Revelar gabarito e comentário▾
GabaritoE — o uso de um service mesh busca externalizar, para a infraestrutura, diversas preocupações transversais, como roteamento de tráfego, telemetria, autenticação mútua (mTLS) e políticas de resiliência, reduzindo a necessidade de implementar essas funcionalidades no código de cada microsserviço.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Arquitetura de Software: Microsserviços, Serverless e Service Mesh
Gabarito: letra E. O service mesh externaliza preocupações transversais (roteamento, telemetria, mTLS, resiliência) para a infraestrutura por meio de proxies sidecar, reduzindo a necessidade de implementá-las no código de cada microsserviço – exatamente o que descreve a alternativa E. As demais alternativas contêm equívocos sobre a relação entre serverless e microsserviços, sobre o funcionamento do service mesh e sobre sua função.
A banca testa o entendimento dos papéis de cada tecnologia e suas complementaridades. O contexto de migração monolito → microsserviços + serverless + service mesh é típico de sistemas distribuídos modernos.
Alternativa
Afirmação
Correta?
Motivo
A
Serverless torna desnecessária a arquitetura de microsserviços
❌
Serverless e microsserviços são complementares; funções serverless podem coexistir com contêineres, não os substituem por definição
B
Service mesh elimina uso da rede e latência com chamadas diretas em memória entre sidecars
❌
A comunicação ocorre via rede (HTTP/gRPC) com proxies sidecar; há overhead, não eliminação de latência
C
Service mesh substitui o orquestrador de contêineres (Kubernetes)
❌
Service mesh gerencia comunicação entre serviços; orquestrador cuida de agendamento, escalonamento e hardware
D
Microsserviços e serverless são mutuamente excludentes
❌
Podem coexistir no mesmo sistema, com serverless para tarefas eventuais e microsserviços para lógica principal
E
Service mesh externaliza preocupações transversais (roteamento, telemetria, mTLS, resiliência) para a infraestrutura
✅
Reduz necessidade de implementar essas funcionalidades no código de cada microsserviço, usando proxies sidecar
Alternativa A — ❌ Incorreta
Afirma que serverless torna desnecessária a arquitetura de microsserviços, mas as duas abordagens são complementares: funções serverless podem substituir ou coexistir com microsserviços em contêineres, não os eliminam por definição. A arquitetura de microsserviços continua sendo a base para organizar o domínio.
Alternativa B — ❌ Incorreta
A comunicação em um service mesh utiliza a rede normalmente, com proxies sidecar que interceptam o tráfego entre serviços. Não há chamadas diretas em memória – os sidecars se comunicam via protocolos de rede (HTTP, gRPC). A afirmação de que elimina latência e falhas de transporte é falsa; na verdade, o service mesh adiciona uma camada (com overhead) para oferecer resiliência e observabilidade.
Alternativa C — ❌ Incorreta
O service mesh não substitui o orquestrador (Kubernetes). Enquanto o orquestrador gerencia agendamento de pods, escalonamento e detecção de falhas de hardware, o service mesh cuida da comunicação entre serviços (roteamento, segurança, métricas). São camadas complementares.
Alternativa D — ❌ Incorreta
Microsserviços e serverless não são excludentes. É perfeitamente possível ter um sistema que combina microsserviços em contêineres com funções serverless (FaaS) – por exemplo, usando serverless para tarefas eventuais ou de baixa frequência, enquanto os microsserviços gerenciam o estado e a lógica principal. A afirmação de que não podem coexistir no mesmo domínio de negócio é incorreta.
Alternativa E — ✅ Correta ⟵ GABARITO
O service mesh (ex.: Istio, Linkerd) insere um proxy sidecar junto a cada instância de microsserviço. Esse proxy assume responsabilidades como roteamento inteligente, coleta de telemetria, autenticação mútua (mTLS), retry e circuit breaking. Dessa forma, essas preocupações transversais (cross-cutting concerns) são externalizadas para a infraestrutura, liberando o código do microsserviço para focar na lógica de negócio – exatamente o que a alternativa descreve.
NÃO CAIA NESSA!
As alternativas B e C exploram o equívoco comum de que service mesh substitui o orquestrador ou que sua comunicação é em memória. Lembre-se: sidecars atuam como proxies de rede, e o mesh é um complemento, não substituto do Kubernetes. A alternativa A e D confundem o papel do serverless – ele é um modelo complementar, não excludente.
Gabarito: letra E – a única que descreve corretamente o objetivo do service mesh.