O que são microsserviços? Vantagens, desafios e quando usar

Microsserviços viraram sinônimo de modernidade arquitetural, mas a verdade é mais sóbria: eles resolvem problemas reais ao custo de uma complexidade enorme. Este guia explica o que são, quando valem a pena e por que, para a maioria dos projetos, começar com um monolito ainda é a decisão mais inteligente.

O que é uma arquitetura de microsserviços

Microsserviços são um estilo arquitetural em que uma aplicação é construída como um conjunto de serviços pequenos, independentes e implantáveis separadamente, cada um responsável por uma capacidade de negócio bem definida. Esses serviços se comunicam por meio de protocolos leves — tipicamente chamadas HTTP sobre uma API seguindo o estilo REST, ou mensagens assíncronas via filas e eventos.

O contraste clássico é com o monolito: uma única aplicação implantável, em que toda a lógica vive no mesmo processo e compartilha o mesmo banco de dados. No monolito, módulos chamam uns aos outros por simples chamadas de função na memória. Em microsserviços, essas chamadas atravessam a rede.

Cada microsserviço idealmente:

Vale notar o que microsserviços não são. Não são "serviços pequenos em quantidade de linhas". O "micro" se refere ao escopo da responsabilidade de negócio, não ao tamanho do código. Um serviço de pagamentos pode ter muitas linhas e ainda assim ser um microsserviço legítimo, porque cobre uma fronteira coesa. Inversamente, dividir o sistema em dezenas de serviços anêmicos que só repassam chamadas não é arquitetura de microsserviços — é fragmentação.

A confusão entre monolito e "código bagunçado"

Um erro comum é equiparar monolito a má arquitetura. Não são a mesma coisa. Um monolito pode ser perfeitamente bem estruturado internamente, com módulos coesos e fronteiras claras — o chamado monolito modular.

A disciplina interna de um monolito vem das mesmas ideias que orientam sistemas distribuídos bem feitos. Os princípios de Arquitetura Limpa ajudam a manter as regras de negócio isoladas de detalhes de infraestrutura, e o DDD (Domain-Driven Design) fornece o conceito de bounded context — o limite dentro do qual um modelo de domínio é consistente. Curiosamente, esses bounded contexts costumam ser exatamente as linhas onde, mais tarde, você cortaria seus microsserviços.

Martin Fowler, ao catalogar padrões de arquitetura corporativa, já alertava que a primeira regra dos sistemas distribuídos é não distribuir a menos que você precise — porque toda chamada remota é ordens de magnitude mais cara e mais frágil do que uma chamada local (Fowler, 2002). Essa "Primeira Lei dos Objetos Distribuídos" continua valendo.

Pense nos números por um instante. Uma chamada de função na memória custa nanossegundos e nunca "falha" sozinha. Uma chamada de rede dentro do mesmo datacenter custa, na melhor das hipóteses, centenas de microssegundos a alguns milissegundos — e pode falhar, atrasar ou retornar pela metade. Quando você transforma uma chamada de método em uma chamada remota, não está só adicionando latência: está adicionando uma classe inteira de modos de falha que antes não existia.

As vantagens reais dos microsserviços

Quando aplicados ao contexto certo, microsserviços entregam benefícios concretos:

Escalabilidade independente

Você pode escalar apenas o serviço que está sob carga. Se o serviço de busca recebe 100x mais tráfego que o de faturamento, você sobe mais instâncias só da busca, sem desperdiçar recursos com o resto.

Autonomia de times

Times podem trabalhar, implantar e liberar suas mudanças sem coordenar um deploy gigante com toda a empresa. Isso reduz o gargalo organizacional — frequentemente o motivo real pelo qual empresas grandes adotam microsserviços.

Aqui aparece a Lei de Conway: organizações tendem a produzir sistemas cuja estrutura espelha a sua própria estrutura de comunicação. Se você tem cinco times independentes, mais cedo ou mais tarde seu sistema tende a se dividir em cinco peças que refletem essas fronteiras de comunicação. Microsserviços, vistos por essa lente, são tanto uma decisão técnica quanto uma decisão organizacional. Adotá-los sem ter a organização compatível costuma gerar atrito constante.

Diversidade tecnológica

Cada serviço pode usar a linguagem ou banco de dados mais adequado ao seu problema. O serviço de machine learning pode ser em Python; o de alta concorrência, em Go.

Essa liberdade tem um lado oculto: cada nova linguagem ou banco é mais uma coisa para operar, monitorar, atualizar e contratar gente que saiba. A "diversidade tecnológica" vira facilmente um zoológico difícil de cuidar. Times maduros costumam limitar conscientemente o leque de tecnologias permitidas, justamente para não pagar esse custo em todo serviço novo.

Isolamento de falhas

Se bem projetado, a falha de um serviço não derruba o sistema inteiro. Um problema no serviço de recomendações não deveria impedir o usuário de finalizar uma compra.

A palavra-chave é "se bem projetado". O isolamento não é automático: ele exige bulkheads (compartimentos que contêm a falha), timeouts agressivos e fallbacks. Sem isso, um serviço lento pode prender todas as threads do chamador e provocar uma falha em cascata — o oposto do isolamento prometido.

Implantação facilitada por containers

A revolução dos microsserviços foi viabilizada por Docker e orquestradores como Kubernetes. Empacotar cada serviço em um container resolve o pesadelo de dependências e torna o deploy independente algo prático em vez de teórico.

Os desafios (que o hype esconde)

Aqui está a parte que entusiastas costumam omitir. Microsserviços trocam a complexidade dentro do código pela complexidade entre serviços — e essa última é muito mais difícil de domar.

A rede não é confiável

Em um monolito, uma chamada de função sempre retorna. Na rede, chamadas falham, atrasam ou se perdem. Você precisa lidar com timeouts, retries, circuit breakers e idempotência. Cada uma dessas é uma fonte de bugs sutis.

Esse conjunto de armadilhas tem nome consagrado: as falácias da computação distribuída, formuladas por engenheiros da Sun Microsystems. As mais citadas são supor que "a rede é confiável", "a latência é zero", "a banda é infinita" e "a topologia não muda". Todo bug clássico de sistemas distribuídos nasce de alguém ter assumido, sem perceber, uma dessas afirmações falsas.

Um cuidado central é a idempotência: se um serviço chama outro, não recebe resposta por timeout e tenta de novo, a operação não pode ser aplicada duas vezes. Um pagamento cobrado em dobro porque o cliente fez retry é um dos bugs mais comuns — e mais caros — desse mundo.

Consistência de dados distribuída

Sem um banco único, não há mais transações ACID atravessando o sistema todo. Aqui entra o teorema CAP: em um sistema distribuído sujeito a partições de rede, você não pode ter, ao mesmo tempo, consistência forte e disponibilidade total — é preciso escolher.

Eric Brewer, autor do teorema, revisitou o tema anos depois para esclarecer que a escolha não é binária e absoluta: na prática, partições são raras, e os sistemas modernos modulam consistência e disponibilidade de forma mais sutil, frequentemente optando por consistência eventual (Brewer, 2012). Mas isso significa que seu sistema precisa tolerar dados temporariamente desatualizados — um modelo mental radicalmente diferente do monolito transacional.

Como você coordena uma operação que envolve vários serviços sem uma transação global? O padrão mais usado é o Saga: a operação vira uma sequência de passos locais, cada um com uma ação compensatória que desfaz seu efeito caso um passo posterior falhe. Reservar o estoque, cobrar o cartão e gerar a nota viram três passos; se a cobrança falha, a compensação devolve o estoque reservado. É poderoso, mas muito mais trabalhoso de raciocinar do que um simples BEGIN/COMMIT.

Observabilidade complexa

Quando uma requisição atravessa oito serviços, descobrir onde ela falhou exige tracing distribuído, logs correlacionados e métricas agregadas. Debugar um sistema distribuído é incomparavelmente mais difícil.

Os três pilares aqui são logs (eventos discretos, idealmente correlacionados por um ID de requisição que atravessa todos os serviços), métricas (números agregados como latência e taxa de erro) e traces (o caminho completo de uma requisição pelos serviços). Sem um correlation ID propagado em cada chamada, investigar um erro vira arqueologia — você fica costurando logs de oito sistemas sem saber quais linhas pertencem à mesma requisição.

Sobrecarga operacional

Cada serviço precisa de pipeline de deploy, monitoramento, alertas, gestão de segredos e versionamento de API. Multiplique isso por dezenas de serviços. Sem uma cultura forte de automação e DevOps, microsserviços viram um fardo.

Contratos e versionamento

Quando o serviço A depende do serviço B, mudar o contrato de B pode quebrar A. Versionar APIs e evoluir contratos sem quebrar consumidores é uma disciplina inteira por si só.

A regra de ouro é a compatibilidade retroativa: ao evoluir uma API, você adiciona campos opcionais em vez de remover ou renomear os existentes. Quebras de contrato precisam de versionamento explícito e de um período de convivência das duas versões. Equipes maduras usam testes de contrato (consumer-driven contracts) para detectar, no CI, quando uma mudança no produtor quebraria um consumidor — antes de chegar à produção.

O monolito distribuído: o pior dos dois mundos

Existe uma armadilha frequente: dividir a aplicação em vários serviços que, na prática, continuam fortemente acoplados. Toda mudança exige alterar e implantar vários serviços juntos; eles compartilham banco de dados; falham em conjunto.

Isso é um monolito distribuído: você pagou todo o custo de complexidade da distribuição e não ganhou nenhum dos benefícios da independência. É, sem exagero, o pior dos dois mundos — e resulta quase sempre de fronteiras mal definidas. Por isso o trabalho de DDD para identificar bons bounded contexts é tão crítico antes de qualquer split.

Como reconhecer que você caiu nessa armadilha? Alguns sinais clássicos: você não consegue implantar um serviço sem implantar outro junto; vários serviços leem e escrevem na mesma tabela; uma mudança de schema obriga um deploy coordenado de meio sistema; os times vivem se bloqueando. Se a "independência" prometida pelos microsserviços não aparece no dia a dia, você provavelmente tem um monolito distribuído com a etiqueta trocada.

Comunicação síncrona vs. assíncrona

Uma decisão estrutural que define muito do comportamento do sistema é como os serviços conversam.

Não há resposta universal. Sistemas reais misturam os dois: síncrono onde a resposta imediata é essencial (validar um login), assíncrono onde dá para processar depois (enviar e-mail de confirmação, atualizar um relatório). A maturidade está em escolher conscientemente, não em adotar um estilo por inércia.

Quando usar microsserviços (e quando não)

A pergunta certa não é "monolito ou microsserviços?", mas "o que meu contexto exige agora?".

Comece com um monolito bem modularizado quando:

Considere migrar para microsserviços quando:

A abordagem mais segura é o monolith-first: construa um monolito modular, deixe os bounded contexts emergirem com o uso real, e extraia microsserviços de forma incremental apenas onde houver dor comprovada. Migrar de um monolito bem feito para microsserviços é viável; tentar começar com microsserviços sem entender o domínio costuma ser um desastre caro.

Quando a extração for inevitável, um padrão útil é o Strangler Fig ("figueira estranguladora"): em vez de reescrever tudo de uma vez, você intercepta o tráfego e vai redirecionando funcionalidades, uma a uma, para novos serviços, enquanto o monolito antigo encolhe gradualmente até poder ser aposentado. É o oposto da reescrita "big bang", que tem histórico notório de fracasso.

Perguntas frequentes

Microsserviços deixam o sistema mais rápido? Em geral, não. A comunicação por rede adiciona latência em comparação a chamadas em memória. O que microsserviços oferecem é escalabilidade e autonomia, não velocidade bruta por requisição.

Posso ter um banco de dados compartilhado entre serviços? Tecnicamente sim, mas é um forte indício de monolito distribuído. O acoplamento por dados anula a independência. O padrão saudável é cada serviço dono do seu próprio armazenamento.

Quantos serviços é "certo"? Não há número mágico. O guia é a fronteira de negócio (bounded context), não uma contagem. Mais serviços do que o domínio justifica só multiplica custo operacional.

Startups deveriam começar com microsserviços? Quase nunca. Antes do product-market fit, as fronteiras do domínio mudam toda semana. Um monolito modular permite refatorar fronteiras rapidamente; microsserviços congelam fronteiras erradas em contratos de rede caros de mudar.

Microsserviços exigem Kubernetes? Não obrigatoriamente, mas a operação de muitos serviços independentes praticamente demanda orquestração e automação. Sem Docker e algo que orquestre containers, a sobrecarga operacional fica insustentável.

Conclusão

Microsserviços são uma ferramenta poderosa para problemas de escala organizacional e técnica, não um upgrade automático de qualidade. Eles trocam a complexidade do código pela complexidade distribuída — rede não confiável, consistência eventual, observabilidade difícil e sobrecarga operacional. Para a maioria dos projetos, começar com um monolito modular, guiado por bons princípios de arquitetura e DDD, é a decisão certa. Adote microsserviços quando a dor real aparecer e você tiver maturidade para pagar o preço — extraindo de forma incremental, com fronteiras claras e contratos versionados — nunca apenas porque está na moda.

Referências