Como modernizar um monólito Java para microsserviços sem comprometer o sistema legado

Modernizar um monólito Java é extrair capacidades com seams claros, preservar disponibilidade e migrar dados com disciplina. Big bang é teatro de risco.

Princípio: strangler fig

Intercepte chamadas na borda, desvie progressivamente para o novo serviço e mantenha o monólito como fallback até o tráfego e a confiança justificarem o corte.

Clients ─► Gateway ─┬─► Monolith (legado)
                    └─► New Service (fatia)

Identificar seams

1. Mapeie módulos por linguagem ubíqua e donos
2. Ache fronteiras com baixo acoplamento de dados
3. Prefira extrair jornadas de leitura antes de escritas complexas
4. Meça acoplamento (imports, tabelas compartilhadas, jobs)

Dados: o ponto que derruba projetos

• Evite shared database como estado final
• Use dual write só com outbox/CDC e reconciação
• Defina ownership de cada entidade
• Aceite consistência eventual onde o negócio permitir

Contratos e compatibilidade

Versionamento de API, testes de contrato e feature flags reduzem o medo do corte. O monólito e o serviço novo precisam coexistir com observabilidade comparável.

public class PricingFacade {
  private final FeatureFlags flags;
  private final LegacyPricing legacy;
  private final PricingClient modern;

  public Price quote(QuoteRequest req) {
    if (flags.enabled("pricing-modern", req.customerId())) {
      return modern.quote(req);
    }
    return legacy.quote(req);
  }
}

Riscos e anti-padrões

• Extrair serviços sem dono de produto/domínio
• Distribuir o monólito em rede mantendo o mesmo modelo de dados
• Ignorar jobs batch e relatórios que acoplam tabelas
• Prometer redução de custo no curto prazo

Ordem sugerida

1. Observabilidade e testes no monólito
2. Seams e modularização interna
3. Extração de leitura (BFF/serviço)
4. Extração de escrita com outbox
5. Desligar código morto com evidência de tráfego zero