Pular para o conteúdo principal

Questão de Engenharia de Software — Conceitos Básicos em Engenharia de Software — FCC 2025

Engenharia de SoftwareConceitos Básicos em Engenharia de Software
Código
fc073225
Banca
FCC
Órgão
Prefeitura de São Paulo - SP
Ano
2025
Nível
Superior
Cargo
Analista de Planejamento e Desenvolvimento Organizacional Tecnologia da Informação e Comunicação
Uma prefeitura está modernizando sua arquitetura de TI para implementar projetos baseados em Machine Learning (ML). Foi decidido que as soluções utilizarão uma arquitetura de microsserviços para melhor escalabilidade e manutenção. Para a implementação flexível e eficiente de microsserviços para modelos de ML, considerando padrões de design e tecnologias modernas,
  1. Acada microsserviço deve conter um pipeline completo de treinamento & inferência, garantindo que modelos sejam recalibrados em tempo real.
  2. Btodos os microsserviços devem ser configurados para compartilhar estados por meio de sistemas de cache em memória como Redis, garantindo que os modelos de ML sejam consistentes.
  3. Cos microsserviços devem ser projetados exclusivamente para ingestão de dados, enquanto modelos de ML devem ser centralizados em um servidor de alto desempenho.
  4. Dos modelos de ML devem ser desacoplados em microsserviços independentes que executem inferências, enquanto pipelines de treinamento permanecem centralizados.
  5. Eé necessário criar microsserviços independentes apenas para serviços de logging e monitoramento, mantendo os modelos acoplados ao backend principal.
Revelar gabarito e comentário

GabaritoD — os modelos de ML devem ser desacoplados em microsserviços independentes que executem inferências, enquanto pipelines de treinamento permanecem centralizados.

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”.

Microsserviços para Machine Learning

Gabarito: letra D. Em arquiteturas modernas de ML, o treinamento e a inferência são pipelines com requisitos distintos: o treinamento demanda recursos computacionais intensivos e dados históricos, sendo mais adequado mantê-lo centralizado; já a inferência deve ser leve, escalável e responsiva, ideal para ser implantada como microsserviços independentes e stateless. A alternativa D é a única que respeita esse desacoplamento.

A banca testa o conhecimento dos princípios de microsserviços aplicados a Machine Learning, especialmente a separação de responsabilidades (Separation of Concerns) e a escalabilidade horizontal.

1Treinamento
Centralizado
Recursos intensivos
Dados históricos
2Inferência
Microsserviços independentes
Leve e stateless
Escalável horizontalmente
3Princípios
Separação de responsabilidades
Desacoplamento
Microsserviços para ML
LEVELsoulevel.com.br
Microsserviços para ML: Treinamento (Centralizado, Recursos intensivos, Dados históricos); Inferência (Microsserviços independentes, Leve e stateless, Escalável horizontalmente); Princípios (Separação de responsabilidades, Desacoplamento)

Alternativa A — ❌ Incorreta

Afirma que cada microsserviço deve conter um pipeline completo de treinamento e inferência. Isso viola o princípio da separação de interesses e torna o serviço pesado, com acoplamento entre processos de longa duração (treino) e requisições em tempo real (inferência). Na prática, treinamento e inferência são ciclos diferentes: o treino é esporádico e intensivo, a inferência é contínua e leve.

Alternativa B — ❌ Incorreta

Propõe compartilhar estados entre microsserviços via cache em memória. Microsserviços devem ser stateless para escalar horizontalmente; o compartilhamento de estado (mesmo em cache) introduz acoplamento e pontos únicos de falha. Modelos de ML podem ser versionados e armazenados em um repositório central, mas o estado da aplicação não deve ser compartilhado entre serviços.

Alternativa C — ❌ Incorreta

Centraliza todo o modelo de ML em um servidor de alto desempenho, reduzindo os microsserviços à mera ingestão de dados. Isso nega os benefícios de escalabilidade e resiliência dos microsserviços. A inferência deve ser distribuída para atender múltiplas requisições simultâneas sem gargalo.

Alternativa D — ✅ Correta ⟵ GABARITO

Desacopla os modelos de ML em microsserviços independentes responsáveis apenas pela inferência, enquanto o pipeline de treinamento permanece centralizado. Essa arquitetura é a recomendada por boas práticas: treinamento pode usar clusters dedicados (ex.: Spark, GPU farms) e a inferência é implantada em contêineres leves escaláveis (ex.: Kubernetes, serverless). O desacoplamento permite versionamento, deploy independente e rollback sem impactar o treinamento.

Alternativa E — ❌ Incorreta

Sugere criar microsserviços apenas para logging e monitoramento, mantendo os modelos acoplados ao backend principal. Isso não aproveita as vantagens dos microsserviços para a própria lógica de ML. A ideia é justamente isolar a inferência para escalar e gerenciar independentemente, não apenas serviços auxiliares.

NÃO CAIA NESSA!

A banca confunde o papel do treinamento e da inferência. O candidato pode achar que tudo deve ser descentralizado (alternativa A) ou centralizado (alternativa C). A chave é lembrar que treinamento é pesado e frequente, inferência é leve e contínua – cada um tem seu lugar na arquitetura.

Gabarito: letra D

Link permanente: /questoes/fc073225