Comunicação entre serviços acumula mais decisões de
longa duração do que qualquer outro tópico de
arquitetura. Protocolos são difíceis de migrar,
contratos de mensagem são difíceis de versionar,
e o que começa como "só uma chamada REST" vira
dependência acoplada por anos. As perguntas abaixo
forçam articular o que está em jogo em cada escolha.
REST ou gRPC para comunicação interna entre serviços?
gRPC ganha em performance (binário, HTTP/2 multiplexado),
tipagem (contrato .proto gerado), e streaming nativo.
Perde em debugging (não é legível sem ferramenta),
em adoção por clientes externos (browser não faz gRPC
direto sem grpc-web), e em tooling de gateway/proxy
que ainda é mais maduro para REST. A regra prática
usada na indústria: REST para APIs expostas externamente
(cliente browser ou mobile) ou onde legibilidade e
flexibilidade de cliente importam; gRPC para comunicação
interna entre serviços onde performance e contrato
forte valem o custo operacional. Hibridismo é comum
e aceitável — API Gateway translating REST externo
para gRPC interno.
API Gateway ou Service Mesh — ou os dois?
API Gateway e Service Mesh não são concorrentes —
operam em camadas diferentes. Gateway opera na borda
norte-sul (tráfego externo entrando no cluster) e
gerencia contratos com clientes externos: auth, rate
limiting por plano de API, versionamento de rota,
developer portal. Service Mesh opera no tráfego
leste-oeste (serviço para serviço dentro do cluster)
e gerencia resiliência e observabilidade: mTLS, retry,
circuit breaker, tracing. Times menores frequentemente
começam com só um API Gateway e adiam service mesh
até que a escala justifique o custo operacional
(Istio tem reputação de complexidade real).
Fila de mensagem ou Kafka?
A distinção fundamental é retenção e reprocessamento.
Filas tradicionais (RabbitMQ, SQS) deletam a mensagem
após consumo bem-sucedido — boas para comandos, tarefas
one-shot, e workloads onde reprocessamento de histórico
não é necessário. Kafka retém mensagens pelo tempo
configurado (dias, semanas) e permite que novos
consumers leiam do início — bom para eventos de
domínio que múltiplos sistemas precisam consumir,
para audit trail, e para pipelines de dados. Se você
precisa de "entregar essa tarefa a um worker", use
fila. Se você precisa de "publicar esse evento para
quem quiser consumir agora ou daqui 3 dias", use Kafka.
Versionamento de API: URL path, header, ou query string?
URL path (/v1/, /v2/) é o padrão mais adotado porque
é explícito, visível em logs, e fácil de rotear no
gateway. A crítica é que viola a ideia REST de que
URL representa recurso, não versão do contrato.
Header (Accept: application/vnd.api.v2+json) é mais
"correto" segundo REST puro mas invisível em logs
e mais difícil de testar no browser. Query string
(?version=2) é conveniente para testes mas raro em
produção porque polui caches e logs. Na prática, URL
path vence por operabilidade, não por pureza semântica.
O que realmente importa: manter v1 funcionando durante
a migração — a estratégia de versionamento é
secundária ao comprometimento de não quebrar clientes.
Coreografia ou orquestração em sagas distribuídas?
Coreografia: cada serviço reage a eventos e emite
os seus próprios. Sem coordenador central. Vantagem:
baixo acoplamento, cada serviço evolui independentemente.
Desvantagem: o fluxo de negócio fica implícito,
distribuído entre vários serviços — difícil de visualizar,
testar, e debugar. Orquestração: um orquestrador
(pode ser um serviço, pode ser um workflow engine
como Temporal ou AWS Step Functions) comanda cada
passo e trata falhas centralmente. Vantagem: o
fluxo é explícito e observável em um lugar.
Desvantagem: o orquestrador vira dependência central.
Regra prática: coreografia para fluxos simples com
2-3 participantes; orquestração para fluxos complexos
com compensações, timeouts e múltiplos participantes.