Arquitetura de microsserviços

Microsserviço é um limite de negócio deployável de forma independente — não um CRUD por tabela. Prefira o menor número de serviços que preserve autonomia e clareza.

Para implementação: golang-microservices, nestjs-microservices, rust-microservices. Contratos HTTP: api-design. Go-live: production-readiness. Consolidar antes de distribuir: modular-monolith. Contextos: ddd. Eventos: event-driven-architecture. Decisão: software-architecture.

Quando (não) usar

Faz sentido quando: times autônomos, escalas distintas, ciclos de release diferentes, falhas isoláveis.

Evite quando: domínio incerto, time pequeno, latência forte entre “serviços”, operação sem observabilidade. Comece modular no monolito (modular-monolith) e extraia com evidência.

Bounded contexts

• Um serviço = um contexto com linguagem ubíqua própria.
• API pública estável; modelo interno privado.
• Proibido: dois serviços compartilhando o mesmo banco de escrita.
• Evite “distributed monolith”: chamadas síncronas em cascata para todo write.