## glossário

O que é Microservices?

O que são Microservices?

Microsserviços são um estilo arquitetural que estrutura a aplicação como um conjunto de serviços pequenos, independentes e organizados por capacidade de negócio. Cada serviço tem seu próprio banco de dados, é implantado separadamente e se comunica com os demais por rede, normalmente via API ou mensageria.

A alternativa é o monólito: toda a aplicação em um único artefato implantável. A escolha entre os dois é uma das decisões mais consequentes — e mais frequentemente equivocadas — da arquitetura de software.

O que os microsserviços entregam

Deploy independente — alterar o serviço de pagamentos não exige republicar o catálogo inteiro.
Escala seletiva — o serviço de busca pode ter vinte réplicas enquanto o de relatórios tem uma.
Autonomia tecnológica — cada serviço pode usar a linguagem e o banco mais adequados ao seu problema.
Isolamento de falhas — um serviço degradado não precisa derrubar o sistema inteiro, se houver contenção adequada.
Times independentes — equipes pequenas assumem serviços de ponta a ponta sem coordenação constante.

O que eles cobram em troca

Aqui mora a parte que costuma ser subestimada. Chamadas que eram invocações de função em memória viram requisições de rede, com latência, falhas parciais e necessidade de retentativa. Transações que o banco garantia com um COMMIT passam a exigir coordenação distribuída. Depurar deixa de ser ler um stack trace e passa a exigir rastreamento distribuído. E a operação multiplica: dez serviços significam dez pipelines, dez monitoramentos, dez conjuntos de alertas.

A mesma operação nos dois modelos

// MONÓLITO — o banco garante atomicidade
await db.transaction(async (tx) => {
  await tx.debitar(contaA, 100);
  await tx.creditar(contaB, 100);
}); // falhou? nada aconteceu

// MICROSSERVIÇOS — sem transação global
await contas.debitar(contaA, 100);
try {
  await contas.creditar(contaB, 100);
} catch (e) {
  await contas.estornar(contaA, 100); // compensação manual
  // e se o estorno também falhar?
}

Quando cada modelo faz sentido

A recomendação mais defendida hoje — inclusive por quem popularizou o termo — é começar pelo monólito. Ele é mais simples de desenvolver, testar e operar, e a maioria dos produtos nunca alcança a escala que justifica a divisão. Microsserviços passam a valer quando o gargalo é organizacional: times demais pisando no mesmo repositório, deploys travados por coordenação, partes do sistema com necessidades de escala radicalmente diferentes.

Um caminho intermediário bastante usado é o monólito modular: um único artefato implantável, mas com fronteiras internas explícitas entre domínios. Isso preserva a simplicidade operacional e deixa a extração de serviços viável quando ela realmente se justificar.

## faq

Perguntas frequentes

Qual o tamanho ideal de um microsserviço?

Não existe medida em linhas de código. O critério útil é a fronteira de domínio: o serviço deve ter uma responsabilidade de negócio coesa e ser mantido confortavelmente por um time pequeno. Se mudanças frequentes exigem alterar vários serviços juntos, a divisão foi feita no lugar errado.

Microsserviços precisam de Kubernetes?

Não obrigatoriamente, mas a operação de muitos serviços independentes é justamente o problema que o Kubernetes resolve. Com poucos serviços, containers gerenciados por plataformas mais simples dão conta com bem menos complexidade.

Como os microsserviços se comunicam?

De duas formas principais. Síncrona, via REST ou gRPC, quando a resposta é necessária imediatamente. E assíncrona, via filas ou eventos como Kafka e RabbitMQ, quando o processamento pode acontecer depois — modelo que reduz acoplamento e melhora a resiliência a falhas temporárias.