Microsserviços no Currículo: Como Descrever Arquitetura Distribuída

Microsserviços no currículo costuma significar muito pouco quando a palavra aparece sozinha, porque ela cobre desde três serviços em uma startup até centenas de componentes numa operação de banco. A vaga de back-end quer saber quantos serviços existiam, como eles conversavam e o que acontecia quando um deles caía. Este guia mostra como descrever arquitetura distribuída com esses fatos, como escrever uma migração de monolito e quando é melhor não usar o termo.

Microsserviço é um serviço com deploy próprio, e a linha deve provar isso

Um serviço se distingue dos módulos de uma aplicação por ter publicação independente e um contrato claro com os outros. Se você consegue subir uma versão nova de um serviço sem mexer nos demais, ele tem essa característica. Se para publicar qualquer mudança é preciso subir tudo junto, a arquitetura é um monolito, por mais que esteja bem dividida em pastas.

Antes: Arquitetura de microsserviços em Java e Node.js.

Depois: Três serviços de pedido, pagamento e estoque, cada um com deploy próprio e banco separado, que se comunicavam por uma API HTTP com contrato versionado.

A versão depois mostra a fronteira. Ela diz quantos serviços havia, o que cada um guardava e como se falavam. Se você trabalhou com um serviço só, descreva o seu e cite os vizinhos com quem ele trocava mensagens.

Conte os serviços que você colocou em produção, e diga o papel de cada um

O número de serviços é a primeira informação que o recrutador procura, mas ele só tem valor junto com a responsabilidade de cada um. Um serviço de notificações que enviava e-mails não pesa o mesmo que um serviço de cobrança que guardava dinheiro e precisava de idempotência. Escolha os dois ou três que você conhece bem e descreva-os.

• O serviço que você criou. Diga o problema que ele resolvia e quem o chamava. Essa é a parte que mais reflete seu trabalho.
• Os serviços que você consumia. Se você era cliente de uma API de outro time, escreva isso como integração, e não como responsabilidade pelo serviço.
• O total da arquitetura.Se houver um número, como “doze serviços”, coloque-o no início da linha, porque é a escala que o leitor vai procurar.

Não invente um total para parecer maior. Se você não sabe quantos serviços existem na empresa, escreva quantos você conhece e deixe o total de fora.

A comunicação entre serviços é o que a vaga quer ver explicado

Serviços se falam por chamadas diretas, por HTTP ou gRPC, ou por mensagens publicadas em uma fila ou tópico. Cada escolha tem um custo. Chamada direta é mais simples de depurar, mas cria dependência de disponibilidade entre os serviços. Mensagem assíncrona desacopla, mas exige tratar duplicidade e falhas de consumo. O guia de currículo de desenvolvedor back-end trata as ferramentas de mensageria com mais detalhe, então aqui o foco é o fluxo. As palavras-chave de desenvolvedor back-end reúnem os termos que a vaga costuma pedir para essa parte.

Descreva um fluxo real, com os passos em ordem. Um pedido que chega ao serviço de pedidos, reserva estoque por mensagem e recebe a confirmação de pagamento por chamada direta mostra a comunicação em dois estilos, e mostra que você entendeu onde cada um cabe.

Antes: Comunicação entre serviços com mensageria e REST.

Depois: Criei o fluxo de reserva de estoque: o serviço de pedidos publicava um evento de pedido confirmado, o estoque consumia a mensagem e respondia com a reserva, e uma falha de consumo voltava para uma fila de reprocessamento.

A versão depois tem o fluxo, o que foi criado e o tratamento de falha. A pergunta seguinte costuma ser o que acontece se a mesma mensagem chegar duas vezes. Se você não sabe responder, escreva o fluxo e não o detalhe de duplicidade.

Observabilidade é onde a arquitetura distribuída se prova no dia a dia

Num sistema com vários serviços, um erro do usuário pode passar por quatro deles antes de aparecer. Por isso a vaga costuma perguntar como você acompanhava o comportamento. Logs centralizados, métricas por serviço e rastreamento de requisições são os três componentes da observabilidade, e cada um responde a uma pergunta diferente.

Escreva as ferramentas que você configurou e o problema que elas ajudaram a resolver. Painel de métricas em Grafana, coleta de traces com OpenTelemetry e busca de logs em uma ferramenta centralizada são exemplos de trabalho concreto. Se você apenas consultava painéis que outra equipe montou, diga isso com clareza, porque o recrutador vai distinguir essa posição da de quem montou o acompanhamento.

Antes: Monitoramento de microsserviços.

Depois: Configurei o rastreamento com OpenTelemetry nos três serviços de pedido, o que permitiu achar em minutos a etapa que atrasava as confirmações de pagamento.

Essa linha tem ferramenta, escopo e um problema encontrado. Se o caso real não tiver um tempo de resolução, descreva a etapa encontrada e deixe o tempo de fora.

Migração de monolito para serviços: descreva a parte extraída e o método

Migrar um sistema grande para serviços costuma ser feito em partes. O método mais comum é extrair uma funcionalidade por vez, redirecionando o tráfego para o novo serviço enquanto o restante continua no sistema antigo. Essa forma de trabalho tem nome, e o currículo se beneficia de dizer qual foi a parte extraída, quanto do tráfego passou para o novo serviço e como a equipe confirmou que o comportamento estava igual.

Antes: Participei da migração de monolito para microsserviços.

Depois: Extraí o módulo de notificações do monolito de cobrança para um serviço próprio, redirecionando o tráfego em etapas de 10, 50 e 100 por cento, com comparação de respostas entre os dois sistemas em cada etapa.

A versão depois mostra o método e o cuidado. Se você não fez a migração inteira, escreva a parte que fez, porque é isso que ela foi.

Consumir uma API de microsserviços não é construir uma arquitetura

Muita gente que trabalha com sistemas distribuídos apenas chama APIs de outros times. Esse trabalho é real e importante, mas a linha precisa dizer a posição de quem escreve. Consumir um serviço é integração, e construir ou operar um é responsabilidade de arquitetura. As duas coisas podem estar no mesmo currículo, cada uma com a sua frase.

Se a sua posição foi de consumo, escreva a integração com o detalhe que você controlou: tratamento de erro, timeout, retentativa, cache ou versão de contrato. O guia sobre como descrever experiência com resultados ajuda a transformar esses detalhes em linhas com efeito.

Quando microsserviços não devem aparecer no currículo

Há casos em que a palavra atrapalha. Um time de três pessoas com uma aplicação e dois serviços auxiliares não tem uma arquitetura de microsserviços, e escrever a expressão em letras maiúsculas só cria a expectativa de uma escala que não existe. Nesses casos, escreva a arquitetura real: um sistema principal, um serviço de apoio e a integração entre eles.

O mesmo vale para o currículo de DevOps, em que a palavra microsserviço aparece com frequência e nem sempre descreve a arquitetura que a pessoa viveu. Use o termo quando ele for exato, e a descrição específica quando não for.

Como fechar: escreva a arquitetura que você viveu, com número, papel e fluxo

A ideia central é esta: microsserviços no currículo valem pelo número de serviços que você conhece, pelo papel de cada um e pelo fluxo entre eles. Quem escreve só a palavra perde a pergunta que a vaga faz, e quem exagera a escala perde credibilidade na primeira conversa de arquitetura. Antes de enviar, copie da vaga os termos de comunicação, mensageria e observabilidade e confira se cada um tem uma frase de experiência que o prove. A análise gratuita do AjustaCV compara o seu currículo com o texto da vaga que você colar, sem cadastro, e mostra quais termos já estão presentes e quais faltam.

Perguntas frequentes