Microsserviços: quando faz sentido — e quando não

"Vamos de microsserviços?" virou quase um reflexo em discussões de arquitetura. O problema é que microsserviços resolvem um conjunto específico de dores — e, fora desse contexto, eles adicionam complexidade sem entregar o benefício prometido.

Neste artigo a gente separa o hype da realidade e mostra como decidir.

O que microsserviços realmente resolvem

Microsserviços brilham quando o gargalo não é mais o código, e sim a organização: muitos times precisando trabalhar e fazer deploy de forma independente, partes do sistema com necessidades de escala muito diferentes, e ciclos de release que não podem mais ser acoplados.

Se a sua dor é essa, faz todo sentido. Se não é, provavelmente você vai pagar o custo sem colher o ganho.

O custo escondido

Distribuir um sistema transforma chamadas de função em chamadas de rede. Com isso vêm latência, falhas parciais, consistência eventual, versionamento de contratos, observabilidade distribuída e uma esteira de deploy bem mais complexa. Para um time pequeno no início de um produto, isso costuma ser um freio — não um acelerador.

Arquitetura boa é a que cabe no seu momento — não a que está na moda.

Nossa regra prática

• Comece simples. Um monólito bem organizado entrega valor mais rápido e com menos partes móveis.
• Modularize bem desde o começo. Fronteiras claras de domínio dentro do monólito facilitam uma futura separação.
• Só quebre em serviços quando a dor justificar. Escala desigual, número de times ou independência de deploy são bons gatilhos; "porque é moderno" não é.

O caminho do meio: monólito modular

Na prática, a maioria dos produtos vive muito bem com um monólito modular: um único deploy, mas com módulos de domínio bem isolados. Quando um módulo realmente precisa escalar ou ganhar autonomia, você o extrai como serviço — de forma cirúrgica, não no grito.

É assim que a gente costuma evoluir os sistemas dos nossos clientes: começando pelo simples, medindo a dor real e investindo em complexidade só quando ela paga a conta.

Como decidir em 4 perguntas

1. Mais de um time precisa fazer deploy de forma independente?
2. Existe uma parte do sistema com necessidade de escala muito diferente do resto?
3. O monólito atual já virou um gargalo de build, deploy ou organização?
4. Você tem maturidade de observabilidade e automação para operar serviços distribuídos?

Se a maioria das respostas for "não", o monólito (bem feito) ainda é o seu melhor amigo.