Como migrar bases de dados de um monolito sem downtime

Por que migrar o banco de dados é o maior desafio dos microsserviços

Quando decidimos transformar um sistema monolítico (uma aplicação única onde todo o código e banco de dados vivem juntos) em microsserviços (pequenos serviços independentes), o maior pesadelo não é reescrever o código, mas sim separar os dados. Em um monolito, tabelas diferentes conversam entre si por meio de chaves estrangeiras e consultas complexas conhecidas como JOINs. Na prática, isso significa que quebrar um banco de dados gigante em pedaços menores sem derrubar a operação exige uma cirurgia de altíssima precisão.

Muitas equipes tentam fazer essa virada de uma só vez, desligando o sistema na sexta-feira à noite e religando na segunda-feira com a nova arquitetura. Esse método, conhecido como big bang, quase sempre resulta em falhas catastróficas, dados corrompidos e horas de indisponibilidade que enfurecem os usuários. Para evitar o caos, precisamos adotar estratégias incrementais que permitam atualizar a infraestrutura de dados com o motor rodando, garantindo a continuidade dos negócios. Se você busca entender os fundamentos dessa separação em sistemas legados, vale conferir nossas dicas sobre como desacoplar bases de dados em microsserviços legados antes de avançar.

Aplicando o padrão Strangler Fig para isolar dados

O padrão Strangler Fig (inspirado em uma figueira que envolve a árvore hospedeira até substituí-la) propõe substituir o sistema antigo de forma gradual. Quando aplicado a bases de dados, ele nos impede de mover todas as tabelas de uma vez. Em vez disso, escolhemos um domínio de negócio específico — como o cadastro de clientes — e criamos um novo banco de dados dedicado exclusivamente a ele, enquanto o restante do monolito continua intacto no banco antigo.

Na prática, isso significa construir uma camada intermediária que decide para onde vai cada requisição de leitura ou escrita. Se a aplicação precisa consultar dados do cliente migrado, ela acessa o novo serviço; se precisa de produtos, ainda recorre ao monolito legado. Essa convivência pacífica reduz drasticamente o risco da mudança, pois qualquer problema localizado pode ser revertido rapidamente sem comprometer o ecossistema inteiro.

Sincronização bidirecional com Change Data Capture

Durante o período de transição, a aplicação antiga e o novo microsserviço precisam coexistir operando sobre dados semelhantes, o que gera o desafio crítico da consistência. Se um cliente atualiza o endereço na interface antiga, essa alteração precisa refletir imediatamente no novo banco de dados, e vice-versa. Para resolver isso sem criar acoplamento frágil no código, utilizamos o Change Data Capture, uma tecnologia que monitora o registro de alterações (log de transações) do banco legado e replica os eventos em tempo real.

Ferramentas como Debezium escutam cada inserção, atualização ou exclusão feita no banco principal e publicam esses eventos em um barramento de mensagens, como o Apache Kafka. O novo microsserviço consome esses eventos e atualiza sua própria base de dados de forma assíncrona. Esse fluxo bidirecional garante que ambas as pontas permaneçam sincronizadas, permitindo que a equipe realize testes de estresse e validações de performance sem medo de perder informações críticas.

Passo a passo da transição em fases seguras

Para executar a migração sem downtime, dividimos o processo em etapas controladas que evitam gargalos operacionais e protegem a integridade das informações transacionais.

A primeira etapa consiste em configurar a replicação assíncrona dos dados legados para a nova base, garantindo que o novo microsserviço receba uma cópia espelhada e atualizada de todo o histórico operacional.

A segunda etapa envolve redirecionar apenas as operações de leitura para o novo serviço, mantendo as escritas no monolito para validação rigorosa dos resultados entregues ao usuário final.

A terceira etapa realiza a virada definitiva das operações de escrita, transformando o novo microsserviço na fonte primária de verdade daquele domínio de negócio específico.

Tratando conflitos e garantindo consistência eventual

Mesmo com uma sincronização eficiente, o atraso de rede (latência) pode criar pequenas janelas onde os dados diferem entre o monolito e o microsserviço. Em arquiteturas distribuídas, aceitamos que a consistência não seja imediata em todos os lugares, mas ela precisa convergir rapidamente para um estado correto. Para mitigar esse efeito, implementamos rotinas de reconciliação em segundo plano que verificam divergências e corrigem eventuais des sincronias antes que afetem o usuário.

Além disso, quando surgem lentidões inesperadas durante essa fase de transição, é fundamental contar com ferramentas de observabilidade para rastrear onde o gargalo se esconde. Caso queira se aprofundar em como monitorar falhas de desempenho nessa fase, veja nosso guia sobre microsserviços lentos e como debugar gargalos com OpenTelemetry. Identificar latências cedo evita que problemas de banco de dados se espalhem pelo sistema.

Considerações finais sobre a migração de dados

Migrar bases de dados de um monolito para microsserviços sem downtime não é um projeto puramente técnico, mas sim um exercício de gestão de riscos e arquitetura evolutiva. O segredo do sucesso reside em fatiar o problema em fatias menores, manter os sistemas legados operando em paralelo com o auxílio do Change Data Capture e validar cada mudança com rigor antes de desligar as estruturas antigas. Com planejamento e paciência operacional, a transição ocorre de forma invisível para o usuário final.