Questão de Conhecimentos Específicos - Suporte · CESGRANRIO BANESE 01/2025 (nº 41)

Conceito-chave: Arquitetura serverless (como AWS Lambda ou Azure Functions) é um modelo onde o provedor de nuvem gerencia os servidores e a escalabilidade automática é nativa: a plataforma cria e destrói instâncias da sua função conforme a demanda. O problema de latência em picos quase sempre está nos limites de simultaneidade (número máximo de execuções paralelas) ou no cold start (inicialização lenta de uma função que estava "adormecida").

• (A) Incorreta: Serverless é projetado exatamente para alta demanda e elasticidade; mover para on-premise (servidores físicos próprios) reintroduziria custo fixo e gargalos de infraestrutura, piorando o problema.
• (B) Incorreta: Servidor compartilhado com escalabilidade manual é o oposto do modelo serverless; você perderia o gerenciamento automático e ainda teria contenção de recursos com outras aplicações.
• (C) Incorreta: Balanceamento de carga manual no código é uma "solução" frágil e desnecessária, pois o provedor já faz o roteamento automático; você estaria reinventando a roda e adicionando complexidade e latência.
• (D) Incorreta: Desativar a escalabilidade automática é o erro inverso: você eliminaria a única coisa que salva a aplicação no pico, causando throttling (rejeição de requisições) e falhas em massa.
• (E) Correta: Ajustar os limites de simultaneidade (concurrency) e, se aplicável, provisionar concurrency reservado (para evitar cold starts) é a prática padrão para lidar com picos em serverless. A banca testa se você sabe que o problema não é o modelo, mas a configuração do serviço.

Armadilha do distrator mais tentador (C): A banca quer que você pense que "balancear carga" é sempre a solução. Mas em serverless, o provedor já distribui as requisições entre instâncias automaticamente. Adicionar um balanceador manual no código é inútil e ainda cria acoplamento e retrabalho. A pegadinha é confundir "problema de infraestrutura" com "problema de código".