Comunicacao microsservicos: 13 padroes para escolher certo

Quando dividi um monólito em microsservicos, a primeira pergunta que veio foi: como eles conversam sem virar uma bagunça? A resposta não é única. Existem padrões de comunicação que resolvem problemas diferentes, e escolher o errado custa caro em latência, retenção de dados e dor de cabeça em produção. Neste guia, comparo os 13 padrões mais usados, com critérios práticos para você decidir com base no seu caso, não na moda.

1. HTTP/REST síncrono

O padrão mais conhecido: um serviço chama o outro via API REST, geralmente com JSON, e espera a resposta na hora. É simples de implementar, debugar e testar, e qualquer linguagem moderna suporta. Uso para operações que precisam de resposta imediata, como consultar o perfil de um usuário. O problema: se o serviço chamado cair, a chamada falha na hora, e a latência da resposta depende do mais lento da cadeia.

Critério: use quando a operação é pontual e o tempo de resposta importa mais que o desacoplamento. Se sua cadeia tem mais de 3 chamadas síncronas em sequência, repense.

2. gRPC

Substitui o JSON por Protocol Buffers e roda sobre HTTP/2. A mensagem é binária, menor e mais rápida de serializar. Suporta streaming bidirecional, o que ajuda em casos como notificações em tempo real. Em testes que fiz, a latência caiu pela metade em comparação ao REST para payloads grandes. Exige contrato definido em .proto e ferramentas específicas, o que aumenta a curva de aprendizado.

Critério: escolha gRPC para comunicação interna entre serviços que você controla, com alto volume de chamadas e necessidade de baixa latência. Para APIs públicas, REST ainda é mais universal.

3. Mensageria assíncrona com filas

Em vez de chamar direto, o serviço publica uma mensagem numa fila (RabbitMQ, Amazon SQS) e outro consome quando puder. O produtor não espera resposta, o que desacopla os serviços no tempo: se o consumidor estiver lento, a mensagem espera. A resiliência aumenta porque a fila funciona como buffer. O custo é a complexidade: você precisa lidar com entrega duplicada, ordem e confirmação de processamento.

Critério: ideal para tarefas que podem ser processadas em segundo plano, como envio de e-mail, geração de relatório ou atualização de cache. A consistência é eventual, então não use para operações que exigem resposta imediata.

4. Barramento de eventos (event bus)

Aqui, os serviços não se conhecem. Um publica um evento (por exemplo, "pedido criado") num barramento (Kafka, NATS), e qualquer serviço interessado assina e reage. O acoplamento é mínimo: adicionar um novo consumidor não exige mudar o produtor. Esse é o padrão que usei para sincronizar estoque, faturamento e notificação sem criar dependências diretas. Exige governança para não virar um caos de eventos sem documentação.

Critério: use quando múltiplos serviços precisam reagir ao mesmo fato de negócio, mas não precisam saber uns dos outros. É o coração de arquiteturas orientadas a eventos.

5. Event sourcing

Em vez de armazenar só o estado atual, você guarda a sequência de eventos que mudaram o estado. Para reconstruir o estado de um pedido, basta reproduzir os eventos. Isso dá auditoria completa e permite calcular estados passados. A desvantagem é a curva de aprendizado alta e a complexidade de lidar com versões de eventos e projeções. Não é para todo sistema.

Critério: vale a pena em domínios onde histórico é crítico, como financeiro ou de compliance. Para um CRUD simples, é over-engineering.

6. CQRS (Command Query Responsibility Segregation)

Separa as operações de escrita (commands) das de leitura (queries). Você pode ter um modelo otimizado para gravar e outro, muitas vezes desnormalizado, para consultar. Em um sistema de catálogo, usei CQRS para que a leitura de produtos fosse rápida mesmo com alta frequência de atualização de preço. A escrita ia para um serviço, e uma projeção atualizava um banco de leitura separado. A complexidade aumenta porque você mantém dois modelos e precisa sincronizá-los.

Critério: aplique quando leitura e escrita têm requisitos de desempenho muito diferentes, ou quando a leitura é muito mais frequente que a escrita.

7. API Gateway

Um ponto único de entrada que roteia requisições para os microsservicos internos. O cliente não precisa saber quantos serviços existem nem seus endereços. O gateway pode fazer autenticação, rate limiting e agregação de respostas. Em um projeto com app mobile, o gateway reduziu de 6 chamadas para 1 na tela inicial, agregando dados de vários serviços. O risco é virar um gargalo ou um monolito disfarçado se você colocar lógica de negócio nele.

Critério: use para expor APIs a clientes externos (web, mobile) e centralizar preocupações transversais. Mantenha o gateway fino, só com roteamento e composição.

8. Service Mesh

Uma camada de infraestrutura (como Istio ou Linkerd) que intercepta a comunicação entre serviços via sidecar proxies. Ela cuida de retry, timeout, circuit breaker, observabilidade e segurança (mTLS) sem que o código do serviço precise implementar isso. Em um ambiente com Kubernetes, instalei o Linkerd e ganhei métricas de latência e taxa de erro sem alterar uma linha de código dos serviços. O custo é operacional: mais componentes para gerenciar e um consumo extra de recursos.

Critério: adote quando você tem muitos serviços e precisa de políticas de resiliência e observabilidade uniformes, mas não quer implementar em cada linguagem.

9. Choreography (coreografia)

Não existe um orquestrador central. Cada serviço decide, ao receber um evento, quais ações tomar e que eventos publicar. É uma coreografia: cada dançarino segue a música sozinho. Isso elimina um ponto único de falha e dá autonomia a cada time. Porém, o fluxo de negócio fica espalhado, e rastrear uma transação completa exige ferramentas de tracing. Em um fluxo de pedidos, usei coreografia para etapas independentes: reservar estoque, cobrar, notificar. Cada uma reagia ao evento "pedido recebido".

Critério: prefira coreografia quando as etapas são independentes e podem falhar sem comprometer as outras. Se o fluxo é rígido e sequencial, a orquestração é mais previsível.

10. Orchestration (orquestração)

Um serviço central (orquestrador) coordena a sequência de chamadas aos outros serviços, decidindo o próximo passo. É como um maestro que rege a orquestra. Facilita o entendimento do fluxo, que fica num lugar só, e o tratamento de erros é mais direto. Usei em um fluxo de onboarding onde cada etapa dependia da anterior: validar dados, criar conta, enviar documento. O problema: o orquestrador vira um ponto central que pode concentrar lógica demais.

Critério: ideal para processos de negócio com várias etapas sequenciais e regras de decisão. Cuidado para não recriar um monolito no orquestrador.

11. Comandos assíncronos com resposta (request/reply)

Uma variação da mensageria: o produtor envia um comando na fila e aguarda a resposta numa fila de resposta temporária. É útil quando a operação é demorada e você não quer bloquear o chamador, mas ainda precisa do resultado. Implementei isso para processar pagamentos que levavam até 30 segundos; o serviço de pedidos não ficava travado, mas recebia a confirmação depois. Exige correlação entre requisição e resposta, geralmente com um ID.

Critério: use quando a operação pode demorar e você quer manter o chamador responsivo, mas precisa do retorno. Se a resposta pode levar minutos, considere um callback via webhook.

12. Webhooks

Um serviço registra uma URL em outro serviço para ser notificado quando algo acontecer. É o padrão de comunicação mais comum entre sistemas externos: o gateway de pagamento avisa seu servidor quando o boleto é pago. A implementação é simples, mas exige que o receptor esteja disponível para receber a chamada e que você lide com retries e segurança (validar a autenticidade). Em um sistema de assinaturas, recebia webhooks de renovação e atualizava o status do cliente.

Critério: prefira webhooks para integrações com terceiros que precisam notificar seu sistema sobre eventos externos. É mais simples que manter uma fila compartilhada com o parceiro.

13. Comunicação baseada em banco de dados compartilhado

Dois serviços leem e escrevem no mesmo banco. É o anti-padrão clássico de microsservicos, porque cria acoplamento forte: mudar o schema de um quebra o outro. Já vi equipes fazerem isso por pressa e depois sofrerem com locks e migrações conflitantes. Em microsservicos, cada serviço deve ter seu próprio banco. Se você precisa de dados de outro serviço, use uma API ou um evento para obtê-los.

Critério: evite esse padrão. Se já existe, planeje a separação gradual, começando pelas tabelas menos críticas. A curto prazo parece simples, a longo prazo é dívida técnica cara.

Qual padrão escolher na prática?

Não existe bala de prata. Comece com REST síncrono para operações simples e de baixa latência. Introduza filas para tarefas em segundo plano que não precisam de resposta imediata. Quando o número de serviços crescer e vários precisarem reagir ao mesmo evento, migre para um barramento de eventos. Se o fluxo for sequencial e rígido, orquestre; se for independente, coreografe. Avalie sempre o custo operacional: cada padrão adiciona infraestrutura e complexidade. Minha regra: comece simples, meça a dor, e só então adicione complexidade. A especificação impressiona, o uso decide.

Perguntas frequentes sobre comunicacao microsservicos

Qual a diferenca entre comunicacao sincrona e assincrona?

Sincrona significa que o chamador espera a resposta na hora, como uma chamada HTTP. Assincrona significa que o chamador envia a mensagem e continua, sem esperar, como publicar numa fila. A sincrona e mais simples, mas cria dependencia de disponibilidade. A assincrona desacopla e aumenta resiliencia, mas exige lidar com consistencia eventual.

Quando usar REST em vez de gRPC?

Use REST quando a API e publica ou consumida por clientes variados, pois JSON e universal e facil de debugar. Use gRPC para comunicacao interna entre servicos que voce controla, com alto volume e necessidade de baixa latencia. gRPC exige contrato .proto e ferramentas especificas, o que aumenta a complexidade.

O que e mais recomendado para microsservicos: filas ou barramento de eventos?

Depende do cenario. Filas (RabbitMQ, SQS) sao melhores para tarefas de processamento em segundo plano, onde uma mensagem tem um unico consumidor. Barramento de eventos (Kafka, NATS) e melhor quando varios servicos precisam reagir ao mesmo fato de negocio, pois cada um consome o evento de forma independente.

Como evitar o problema de consistencia em comunicacao assincrona?

Aceite a consistencia eventual e projete o sistema para lidar com atrasos. Use sagas para coordenar transacoes distribuídas, com compensacoes em caso de falha. Monitore a fila e implemente retries com backoff. Em muitos casos, a consistencia eventual e aceitavel para o negocio, mas precisa ser comunicada aos usuarios.

O que e um saga pattern em microsservicos?

Saga e um padrao para gerenciar transacoes distribuídas em microsservicos. Em vez de uma transacao atomica, cada etapa e uma transacao local que publica um evento. Se uma etapa falha, etapas anteriores sao compensadas com acoes reversas. Existem duas formas: coreografada (cada servico decide o proximo passo) e orquestrada (um coordenador central guia a saga).

Preciso usar service mesh desde o inicio?

Nao. Service mesh adiciona complexidade operacional significativa. Comece com poucos servicos e implemente resiliencia no codigo (retry, timeout, circuit breaker) se necessario. Adote service mesh quando tiver muitos servicos e precisar de politicas uniformes de observabilidade e seguranca sem duplicar codigo em cada linguagem.