Microsserviços

Toda aplicação começa pequena. Um único codebase, uma equipe, um banco de dados. À medida que o produto cresce — mais funcionalidades, mais usuários, mais desenvolvedores — o que era simplicidade vira peso: qualquer mudança em qualquer parte exige testar tudo, o deploy é um evento único que afeta o sistema inteiro, e times diferentes disputam o mesmo repositório.

Microsserviços é a resposta arquitetural a esse crescimento. Em vez de uma aplicação monolítica, o sistema é decomposto em serviços pequenos e independentes — cada um responsável por uma capacidade específica, com seu próprio processo, seu próprio banco de dados quando necessário, e comunicação entre serviços via API. O checkout é um serviço. O catálogo de produtos é outro. O sistema de notificação é outro. Cada um pode ser desenvolvido, testado e implantado de forma independente.

É o oposto do monólito — e essa diferença tem consequências profundas, para o bem e para o mal.

O monólito é a arquitetura padrão para sistemas novos — e com razão. Um único codebase, um único banco de dados, um único processo para fazer deploy. Simples de desenvolver, simples de depurar, simples de operar. Para equipes pequenas e sistemas jovens, monólito é quase sempre a escolha correta.

O problema do monólito emerge com o crescimento. Quando a aplicação tem centenas de módulos interdependentes, uma mudança em qualquer ponto pode quebrar algo distante. O build demora minutos ou horas. O deploy é um risco — uma pequena mudança exige parar e reiniciar o sistema inteiro. Times diferentes disputam o mesmo repositório, criando conflitos e gargalos de coordenação. Escalar um componente específico (o checkout, por exemplo) exige escalar a aplicação inteira.

Os microsserviços resolvem esses problemas ao custo de complexidade distribuída. Cada serviço pode ser desenvolvido e implantado de forma independente. Times diferentes podem trabalhar em serviços diferentes sem conflito. Escalar o checkout não afeta o catálogo. Se o serviço de recomendação cai, o restante do sistema continua funcionando.

A troca não é gratuita — e entender o que se ganha e o que se perde é o centro da decisão arquitetural.

A promessa de independência tem um custo: tudo que antes era simples dentro de um monólito vira problema de rede distribuída.

Comunicação entre serviços: em vez de uma chamada de função local, serviços se comunicam via HTTP ou mensageria. Isso adiciona latência, e falhas de rede se tornam uma classe nova de problemas. O que acontece quando o serviço B está fora do ar e o serviço A depende dele? É necessário decidir sobre retentativas, timeouts, circuit breakers.

Consistência de dados: cada serviço tem seu próprio banco de dados — o que é a prática correta em microsserviços. Mas isso significa que não há transação única que abrange múltiplos serviços. Uma operação que antes era um INSERT e um UPDATE numa única transação vira um coreografia de eventos entre serviços, com todo o problema de consistência eventual que isso implica.

Observabilidade: num monólito, um erro tem um stack trace. Em microsserviços, uma requisição passa por cinco ou dez serviços antes de retornar — e identificar onde a falha aconteceu exige rastreamento distribuído, correlação de logs entre serviços e ferramentas específicas como Jaeger ou Zipkin.

Overhead operacional: cinco serviços independentes exigem cinco repositórios, cinco pipelines de CI/CD, cinco configurações de monitoramento, cinco políticas de deploy. O que escala o produto escala também a carga de operação.

A migração de monólito para microsserviços raramente acontece de uma vez. O padrão mais comum é o strangler fig — identificar um domínio do monólito que pode ser extraído, criar um serviço independente para ele, redirecionar o tráfego gradualmente e, ao longo do tempo, esvaziar o monólito.

A premissa para uma migração bem-sucedida é ter fronteiras de domínio bem definidas antes de extrair. Microsserviços que refletem cortes de domínio de negócio funcionam. Microsserviços que refletem cortes técnicos arbitrários criam dependências camufladas que tornam o sistema pior que o monólito original.

O anti-padrão mais comum é o monólito distribuído — um sistema onde os serviços são fisicamente separados, mas logicamente acoplados. Cada deploy ainda exige coordenar múltiplos serviços ao mesmo tempo. Cada mudança ainda afeta metade do sistema. O time ganhou complexidade de rede sem ganhar independência de deploy. Esse resultado é o pior dos dois mundos.

A pergunta certa antes de migrar não é "devemos usar microsserviços?" — é "quais são as fronteiras de domínio do nosso negócio, e o nosso sistema reflete essas fronteiras?". A resposta a essa segunda pergunta determina se microsserviços vão ajudar ou piorar.

A Lei de Conway afirma que sistemas de software tendem a refletir a estrutura de comunicação das organizações que os constroem. Equipes separadas produzem sistemas separados. Equipes integradas produzem sistemas integrados.

Isso tem uma implicação direta para microsserviços: a decomposição técnica precisa estar alinhada com a decomposição organizacional. Times que "possuem" serviços independentes produzem microsserviços saudáveis. Times que precisam coordenar constantemente para fazer qualquer mudança produzem o monólito distribuído descrito acima.

A estratégia inversa também é válida — usar a decomposição desejada do sistema para informar como organizar os times. Se queremos que checkout, catálogo e pagamentos sejam serviços independentes, construir times independentes ao redor de cada domínio acelera a migração e sustenta a independência no longo prazo.

A adoção de microsserviços em escala criou um ecossistema de ferramentas para resolver os problemas que a arquitetura introduz.

Service mesh (Istio, Linkerd): camada de infraestrutura que gerencia comunicação entre serviços — load balancing, autenticação mútua, rastreamento e circuit breaking sem modificar o código da aplicação.

API Gateway (Kong, AWS API Gateway): ponto de entrada único para requisições externas, que roteia para os serviços internos corretos. Centraliza autenticação, rate limiting e monitoramento de tráfego externo.

Message broker (Kafka, RabbitMQ): comunicação assíncrona entre serviços via mensagens — desacopla produtor e consumidor e absorve picos de tráfego sem propagá-los diretamente.

Kubernetes: plataforma de orquestração de containers que gerencia onde e como cada serviço roda — scaling, self-healing, service discovery. Microsserviços e Kubernetes tornaram-se inseparáveis na prática.

Microsserviços é um tema onde a adoção prematura causa dano real. A maioria das PMEs que desenvolve software internamente não está no ponto de complexidade onde microsserviços pagam seus custos — e adotar a arquitetura por influência de tendência técnica cria overhead operacional que drena a equipe sem entregar benefício proporcional.

O critério correto para avaliar microsserviços não é tecnológico — é organizacional e de escala. Quantos desenvolvedores estão conflitando no mesmo codebase? Qual é a frequência e o risco dos deploys? Existem domínios de negócio com ciclos de mudança tão diferentes que o acoplamento atual gera custo real? Se as respostas não forem "muitos", "alto" e "sim", monólito bem estruturado é a resposta correta.

Para organizações que chegam ao ponto de considerar microsserviços, o investimento em definir fronteiras de domínio antes de escrever uma linha de código de migração é o que separa projetos bem-sucedidos de projetos que trocam um problema por cinco.