De Monolito a Microsserviços: Um Guia Prático para CTOs de Startups em Crescimento
Seu monolito trouxe você até aqui. Permitiu que uma equipe pequena entregasse rápido, fizesse deploy com um único pipeline e depurasse com um stack trace em vez de rastrear logs por cinco serviços diferentes. Funcionou. E se você seguiu os princípios de um monolito modular bem projetado, ele deu uma base sólida.
Mas agora algo mudou. Você tem três equipes trabalhando no mesmo repositório e os conflitos de merge são constantes. O módulo de processamento de pagamentos precisa escalar de forma diferente do de notificações. Um deploy que deveria levar dez minutos demora uma hora porque é preciso coordenar entre equipes. Um bug no módulo de reporting bloqueia o release de uma funcionalidade de faturamento que está pronta há uma semana.
Esses são sinais reais. E a resposta não é "vamos reescrever tudo em microsserviços neste trimestre". A resposta é evoluir gradualmente.
Quando realmente é hora de migrar
Você não migra porque microsserviços estão na moda. Migra porque o monolito se tornou um gargalo para o seu negócio. Estes são os sinais concretos:
Múltiplas equipes se atropelando. Duas equipes tocam o mesmo código, os PRs se bloqueiam mutuamente, e cada merge exige coordenação que consome mais tempo do que o desenvolvimento em si. A lei de Conway começa a fazer efeito: sua arquitetura precisa refletir sua organização.
Necessidades de escala divergentes. Sua API de busca precisa escalar horizontalmente com o tráfego de usuários, mas seu serviço de processamento de arquivos precisa de máquinas com mais RAM e CPU. Você escala todo o monolito para satisfazer o componente mais exigente, pagando infraestrutura que o resto não precisa.
Deploys longos demais e arriscados. Uma mudança de três linhas exige deploy de toda a aplicação. O pipeline de CI demora 45 minutos. E cada deploy é um evento que gera ansiedade porque qualquer parte do sistema pode quebrar.
Uma falha derruba tudo. Um memory leak no módulo de reporting derruba a API de clientes, o dashboard de administração e o sistema de faturamento. Não há isolamento de falhas.
Se você reconhece dois ou mais desses sinais, é hora de planejar a migração. Se vê apenas um, provavelmente pode resolver o problema com melhor modularização interna.
O Strangler Fig Pattern: não reescreva, extraia
A metáfora vem da figueira estranguladora, uma planta que cresce ao redor de uma árvore existente até eventualmente substituí-la por completo. Seu monolito é a árvore. Os novos serviços são a figueira. E a chave é que a árvore continua viva enquanto a figueira cresce.
Você não reescreve o monolito. Extrai serviços um a um, gradualmente, enquanto o monolito continua funcionando em produção. Cada extração é um passo pequeno e controlado. Se algo dá errado, o monolito continua lá como fallback.
Passo 1: Identifique os limites
Antes de extrair qualquer coisa, você precisa de um mapa claro dos módulos do seu monolito e suas dependências. Se projetou um monolito modular com bounded contexts bem definidos, essa parte é mais simples. Se não, é hora de fazer isso.
Procure as costuras naturais: módulos que se comunicam com o restante através de interfaces claras, que têm seu próprio modelo de dados, que representam um domínio de negócio distinto. Em termos de Domain-Driven Design, você está procurando bounded contexts.
Desenhe o grafo de dependências. Identifique quais módulos dependem de quais. Os que têm menos dependências de entrada e saída são os candidatos mais fáceis para a extração.
Passo 2: Extraia o módulo de maior dor primeiro
Não comece pelo módulo mais fácil nem pelo mais difícil. Comece pelo que causa mais dor. Normalmente é o que cumpre uma ou mais destas condições:
- Escala de forma diferente do resto do sistema.
- Muda com muita frequência e gera conflitos com outras equipes.
- Tem requisitos tecnológicos distintos (precisa de GPUs, um banco de dados diferente, um runtime específico).
- Suas falhas afetam desproporcionalmente o resto do sistema.
Extraia esse módulo como um serviço independente. Faça deploy separado. Dê a ele seu próprio pipeline de CI/CD. Atribua uma equipe que seja sua dona.
Passo 3: Coloque um API gateway ou reverse proxy na frente
Aqui é onde a mágica do Strangler Fig acontece. Você coloca um API gateway (Kong, NGINX, AWS API Gateway, Traefik) na frente de todo o sistema. As requisições que antes iam direto ao monolito agora passam pelo gateway.
O gateway decide: esta requisição vai para o novo serviço, esta outra continua indo para o monolito. Você pode fazer a mudança gradualmente — começar redirecionando 5% do tráfego para o novo serviço, monitorar, e subir progressivamente até 100%.
Se o novo serviço falhar, o gateway pode redirecionar de volta ao monolito. Migração sem risco existencial.
Passo 4: Mova os dados (a parte mais difícil)
Aqui é onde a maioria das migrações se complica. Enquanto seu novo serviço continuar lendo e escrevendo no mesmo banco de dados do monolito, você não tem um microsserviço de verdade — tem um monolito distribuído, que é o pior dos dois mundos.
O objetivo é que cada serviço tenha seu próprio banco de dados. O caminho para chegar lá:
- Dual writes. O novo serviço escreve no seu próprio banco de dados E no do monolito durante um período de transição. Você verifica que os dados são consistentes.
- Sincronização por eventos. Você introduz um sistema de eventos (Kafka, RabbitMQ, SNS/SQS) para manter os dados sincronizados entre o serviço e o monolito.
- Cutover. Quando confia que o novo serviço é a fonte de verdade, elimina a escrita no banco do monolito. Os outros módulos que precisam desses dados os obtêm pela API do novo serviço ou consomem seus eventos.
Aceite que haverá um período de eventual consistency. Não tente manter transações ACID entre serviços — esse caminho leva a distributed transactions e two-phase commits, que são frágeis e lentos.
Passo 5: Repita
Extraia o próximo serviço. E o próximo. Cada extração deveria levar semanas, não meses. Se uma extração está demorando três meses, provavelmente você está extraindo um módulo grande demais ou as dependências não estavam tão claras quanto pensava.
A cada extração, o monolito fica menor e mais gerenciável. Eventualmente, o que resta é mais um serviço — ou se decompõe nos últimos dois ou três serviços de forma natural.
A infraestrutura que você precisa
Microsserviços não são só código em repositórios separados. Precisam de infraestrutura de suporte que não existia no seu mundo monolítico:
Service discovery. Os serviços precisam se encontrar. Consul, DNS interno do Kubernetes, ou o service discovery do seu cloud provider.
Logging centralizado. Com dez serviços, você não pode fazer SSH em cada máquina para ler logs. Precisa de ELK Stack, Datadog, Grafana Loki — um lugar onde todos os logs convergem.
Distributed tracing. Uma requisição do usuário pode tocar cinco serviços. Sem tracing (Jaeger, Zipkin, Datadog APM), depurar um erro é adivinhar em qual serviço se originou. Implemente OpenTelemetry desde o primeiro serviço.
CI/CD por serviço. Cada serviço tem seu próprio pipeline. Mudou o serviço de pagamentos, só faz deploy do serviço de pagamentos. GitHub Actions, GitLab CI ou a ferramenta que usar, mas independente por serviço.
Monitoramento e alertas. Health checks, métricas de latência, taxas de erro, saturação de recursos — por serviço. Se você não consegue ver o estado de cada serviço num dashboard, está navegando às cegas.
O que não fazer
Não extraia tudo de uma vez. A tentação de "vamos fazer a migração completa num trimestre" é forte. Resista. Cada extração é um risco controlado. Dez extrações simultâneas são caos.
Não crie nano-serviços. Um serviço que só tem um endpoint e 200 linhas de código não deveria ser um serviço. Tem todo o overhead operacional de um microsserviço sem nenhum benefício. Um serviço deve representar um domínio de negócio com sentido próprio.
Não comece pelo módulo mais acoplado. Se o módulo de usuários está entrelaçado com todo o sistema, é o pior candidato para a primeira extração. Comece por algo com menos dependências.
Não esqueça o monitoramento. Cada serviço que você extrai sem monitoramento adequado é uma caixa-preta em produção. Primeiro observabilidade, depois extração.
Estrutura de equipes: cada serviço precisa de um dono
Um microsserviço sem equipe responsável é um serviço órfão. E serviços órfãos acumulam dívida técnica em velocidade alarmante porque ninguém se sente dono de mantê-los.
Cada serviço precisa de uma equipe que seja sua dona clara. Essa equipe decide seu roadmap, gerencia seus deploys, responde quando falha às três da manhã. Não precisa ser uma equipe dedicada exclusivamente a esse serviço — uma equipe pode ser dona de dois ou três serviços relacionados. Mas a propriedade precisa ser explícita.
Isso é exatamente o que descreve a lei de Conway invertida: você projeta sua arquitetura para que reflita a estrutura de equipes que quer ter. Se quer equipes autônomas que entreguem de forma independente, precisa de serviços que possam ser desenvolvidos e deployados de forma independente.
A migração é um processo, não um projeto
A migração de monolito para microsserviços não tem uma data de fim num Gantt chart. É um processo contínuo que evolui com sua organização. Você extrai serviços quando a dor justifica, não porque existe um plano que diz que é a hora.
Na Conectia, trabalhamos com startups europeias que estão exatamente nesse ponto: o monolito serviu para chegar ao product-market fit, e agora precisam evoluir a arquitetura para escalar. Os engenheiros seniores e arquitetos da América Latina que fornecemos já guiaram essa transição múltiplas vezes — sabem o que extrair primeiro, como evitar os erros clássicos das migrações distribuídas, e como fazer isso sem parar a entrega de funcionalidades.
Porque essa é a chave: seu negócio não pode parar enquanto você migra. Os usuários continuam usando o produto. O time de produto continua pedindo funcionalidades. A migração precisa acontecer em paralelo a tudo isso. E isso exige engenheiros que já fizeram isso antes.
Seu monolito está virando gargalo? Fale com um CTO — conectamos você com arquitetos seniores que já guiaram essa transição sem parar a entrega.
