Migrando um monolito PHP para microsserviços em Go: o que aprendi na prática

Toda vez que um monolito PHP começa a demorar mais de 500ms em endpoints críticos, aparece a mesma pergunta na reunião de arquitetura: "e se migrássemos pra Go?". Depois de conduzir migrações desse tipo em contextos de varejo, e-commerce e sistemas transacionais em empresas como Pizza Hut e BairesDev, aprendi que a resposta quase nunca é a migração completa — é uma migração cirúrgica, feita por partes, com objetivos numéricos claros.

Por que Go venceu PHP em performance no meu contexto

PHP-FPM tem overhead de bootstrap por request. Cada chamada carrega autoloader, config e conexões, mesmo com OPcache agressivo. Em endpoints com centenas de queries e chamadas HTTP externas, isso escala mal.

Go traz três vantagens concretas para APIs de alto tráfego:

• Goroutines para paralelizar chamadas I/O sem thread pool custoso.
• Runtime persistente: conexões, caches e pools sobrevivem entre requests.
• Compilação estática: binário único, deploy simples, cold start em milissegundos.

Em uma migração recente de um serviço de precificação, o P95 caiu de 420ms (PHP 8.1 + Laravel) para 90ms (Go 1.22 + Fiber) — mesma carga, mesmo banco, metade do custo de infra.

Estratégia: Strangler Fig, não Big Bang

Nunca reescreva tudo de uma vez. O padrão que funciona na prática é o Strangler Fig: você coloca um proxy (nginx, API Gateway, ou um roteador em Go) na frente do monolito PHP e vai redirecionando rotas para o serviço novo em Go, uma de cada vez.

Ordem de migração que uso:

1. Endpoints de leitura de alto tráfego (listagens, buscas, health checks). Baixo risco, alto ganho de performance.
2. Serviços de background (workers de fila, jobs agendados). Já rodam isolados, migração natural.
3. APIs de escrita idempotentes (criação com UUID gerado pelo client). Dá pra rodar em dual-write pra validar.
4. Core transacional (checkout, pagamento). Só depois que a stack Go estiver madura e observabilidade estiver sólida.

Erros caros que já cometi

1. Reescrever a lógica de negócio junto com a stack

Migração de linguagem e refatoração de domínio ao mesmo tempo é receita pra desastre. Traduza a lógica literalmenteprimeiro. Refactore depois, com testes de contrato garantindo paridade.

2. Ignorar o comportamento de erro entre stacks

PHP lança exception; Go retorna error como valor. Isso muda contratos: um endpoint que retornava 500 em PHP pode retornar 200 com payload vazio em Go se o error não for tratado. Escreva testes de integração comparando os dois antes de cortar tráfego.

3. Subir Go sem observabilidade equivalente

Se o PHP tem New Relic, o Go precisa de OpenTelemetry configurado desde o dia zero. Não migre um serviço crítico "no escuro".

Quando NÃO migrar

Se o monolito PHP roda em < 200ms P95, custa pouco pra escalar e o time domina a stack, não migre. A migração custa 6-18 meses de foco de engenharia. Só faz sentido quando existe um problema mensurável de performance, custo ou capacidade de time.

Precisa de ajuda pra planejar uma migração assim? Ver consultoria em arquitetura ou falar por email.