Arquitetura de microsserviços em Go: quando usar (e quando NÃO usar)

Microsserviços em Go viraram default em stacks modernas. Empresas de varejo global (incluindo onde trabalho hoje) processam centenas de milhares de transações diárias em serviços Go compactos. Mas microsserviço não é fim em si — é uma escolha de organização de time antes de ser escolha técnica. Aqui vai quando faz sentido e quando não.

Quando USAR microsserviços em Go

1. Múltiplos times entregando em paralelo

A Lei de Conway é real: seu sistema espelha sua organização. Se você tem 3+ times trabalhando no mesmo repositório e brigando por deploy, microsserviços dão autonomia. Um serviço por bounded context, um time dono, deploy independente.

2. Cargas de trabalho com perfis muito diferentes

Um serviço faz 10 RPS de escrita transacional, outro faz 5000 RPS de leitura de catálogo. Escalar tudo junto é caro. Separar permite políticas de scaling e dimensionamento de recursos independentes — Go brilha aqui porque cada serviço custa poucos MB de RAM.

3. Requisitos de resiliência diferentes

Checkout precisa de 99,99%. Newsletter precisa de 99%. Isolar em serviços separados evita que uma queda em algo secundário derrube tudo. Com Go + Kubernetes você configura circuit breakers, timeouts e retries por serviço.

Quando NÃO usar

1. Time menor que 8 engenheiros

Microsserviços exigem infra: service mesh, tracing distribuído, CI/CD por serviço, registry, autenticação inter-serviços. Isso é 1-2 pessoas cuidando de plataforma o tempo todo. Time pequeno = monolito modular (também em Go, se quiser).

2. Produto ainda buscando product-market fit

Você vai pivotar a modelagem 4 vezes nos próximos 6 meses. Refatorar um monolito é chato; refatorar uma malha de serviços é traumático. Mantenha um único deployable até o domínio estabilizar.

3. Domínio fortemente transacional acoplado

Se 80% das operações precisam de consistência forte entre entidades (financeiro, contábil, estoque), fragmentar em serviços te obriga a implementar sagas, outbox pattern, eventual consistency — complexidade exponencial. Monolito com boa modelagem quase sempre vence.

Um caminho seguro: Modular Monolith em Go primeiro

Padrão que uso em novos projetos: monolito Go organizado em pacotes por domínio (internal/pricing, internal/orders), com dependências entre módulos passando somente por interfaces bem definidas. Deploy único. Testes rápidos. Quando um módulo virar gargalo de time ou carga, extrair pra serviço leva semanas, não meses — porque a fronteira já existe.

Stack Go que recomendo em 2026

• HTTP: net/http puro (stdlib está ótima com Go 1.22+) ou chi se quiser router expressivo
• DB: pgx pra Postgres, sqlc pra type-safe queries
• Observabilidade: OpenTelemetry SDK + collector, exporta pra Datadog/New Relic/Grafana
• Mensageria: SQS/SNS na AWS, Kafka se precisar de replay
• Deploy: containers em EKS/ECS, ou Fly.io/Railway se quiser simplicidade

Discutindo se microsserviços fazem sentido pro seu produto? Posso ajudar com uma consultoria de arquitetura ou falar por email.