Decomposição de Monólito em Microserviços: Granularidade e Governança de Dados · kusmin

A transição de uma arquitetura monolítica para uma baseada em microserviços pode trazer benefícios como escalabilidade independente, ciclos de desenvolvimento mais rápidos e maior flexibilidade na adoção de tecnologias. No entanto, definir como decompor corretamente o monólito — em especial quanto à granularidade de cada serviço e à governança de dados — é um dos maiores desafios. Neste artigo, vamos abordar:

Por que migrar de um monólito para microserviços?
Estratégias para encontrar a granularidade adequada de cada serviço.
Como definir a governança de dados em cada microserviço.

1. Por que Migrar de um Monólito para Microserviços?

1.1 Motivação Principal

Muitos monólitos crescem ao ponto de se tornarem complexos e difíceis de manter. Qualquer alteração exige um entendimento abrangente de todo o sistema, gerando impacto em diversas partes. Em contraste, microserviços permitem:

Escalabilidade Independente: Cada serviço pode ser escalado de acordo com sua demanda.
Ciclos de Deploy Independentes: É possível evoluir e publicar um microserviço sem precisar subir todo o sistema.
Escolha de Tecnologias: Cada equipe pode adotar linguagens ou frameworks diferentes, quando necessário.

1.2 Riscos e Desafios

Por outro lado, microserviços trazem uma complexidade de orquestração e comunicação distribuída, demandam estratégias de observabilidade (logs, métricas, tracing distribuído) e requerem governança cuidadosa de dados e APIs.

2. Encontrando a Granularidade Certa para o Serviço

2.1 Fatores de Domínio

Uma das maneiras mais assertivas de definir a granularidade é observar o domínio de negócio. Na abordagem de Domain-Driven Design (DDD), busca-se identificar bounded contexts — áreas de negócio com modelos e linguagens próprias. Cada bounded context pode ser um candidato a microserviço ou um conjunto de microserviços, dependendo do tamanho e coesão interna.

Perguntas a fazer:

“Este agrupamento de funcionalidades está coeso em termos de regras de negócio?”
“Eles compartilham dados e invariantes de forma natural?”
“Há um modelo de domínio suficientemente distinto para justificar um serviço exclusivo?”

2.2 Limitar Dependências Interiores

Para evitar criar “microlitos” (ou seja, serviços ainda grandes e interdependentes), é útil manter a regra: tudo que pertence a um serviço deve ser manipulado internamente. Se há dados e regras espalhados em múltiplos lugares, é um sinal de que talvez seja preciso quebrar ainda mais ou rever as fronteiras.

2.3 Escalabilidade e Carga

Analise também onde o monólito sofre mais carga. Se o fluxo de “busca de produtos” tem muito mais requisições que o restante do sistema, talvez valha a pena isolar essa funcionalidade em um microserviço especializado, escalando-o separadamente. A necessidade de escalabilidade independente pode ser um critério claro para separar um serviço.

2.4 Dependências Externas

Serviços que conversam extensivamente com terceiros (pagamentos, APIs de parceiros, gateways de envio etc.) podem ser bons candidatos a um microserviço isolado. Assim, todo o fluxo de integrações externas fica encapsulado, evitando espalhar complexidade pelo sistema.

2.5 Equilíbrio: Evitar Servições “Extremamente Pequenos”

Microserviços muito pequenos podem gerar overhead de comunicação e governança. Cada serviço demanda pipeline de CI/CD, monitoramento, logs e gestão de configuração. Exagerar na granularidade cria um ecossistema de dezenas ou centenas de serviços, tornando o projeto difícil de coordenar. Regra prática: mantenha serviços focados em um subdomínio coeso ou “capítulo” claro do negócio, evitando separar funcionalidades minúsculas que não justifiquem um serviço autônomo.

3. Definindo a Governança de Dados

3.1 Cada Microserviço com sua Base de Dados

Um dos pilares dos microserviços é banco de dados independente — cada serviço controla seu armazenamento e não acessa diretamente o banco do outro. Isso garante isolação e evita “transações distribuídas” complicadas. Entretanto, surgem desafios:

Replicação de Dados: Se dois serviços precisam de informações semelhantes (por exemplo, dados do cliente), é comum replicar parte dos dados usando mensageria ou eventos (eventual consistency).
Exposição de APIs: Em vez de ler diretamente a tabela do outro serviço, cada microserviço deve chamar a API pública do outro (REST, gRPC ou evento) para buscar ou atualizar informações.

3.2 Estratégia de Sincronização

Para manter consistência:

Event-Driven: Sempre que algo muda no serviço A, ele publica um evento (ex.: “ClienteAtualizado”). O serviço B, que precisa dessa informação, consome o evento e atualiza sua cópia local.
Request-Response: No momento em que o serviço B precisa, chama a API de A para obter dados atualizados. Esse modelo gera acoplamento síncrono e pode aumentar a latência.

3.3 Definir um “Dono” para Cada Dado

No monólito, uma tabela pode ser usada por vários módulos. Em microserviços, é essencial delegar cada “entidade” ou “agregado” a um serviço dono. Qualquer modificação nessa entidade deve ser feita apenas pelo serviço proprietário:

Exemplo: O serviço de “Clientes” é o dono das informações de perfil do cliente; o serviço de “Pedidos” não pode alterar esses dados, só consultá-los (ou receber eventos de atualização).

Essa governança garante que as regras de negócio ligadas à entidade fiquem no lugar certo, evitando duplicações ou conflitos de versão.

3.4 Políticas de Segurança e Acesso

Se o sistema lida com dados sensíveis (ex.: informações pessoais, transações financeiras), cada microserviço deve ter políticas claras de acesso. Só o serviço dono pode ler/escrever dados críticos; os demais devem fazer chamadas autenticadas via APIs, respeitando princípios como OAuth2, tokens JWT, ou certificações mTLS.

4. Passo a Passo de Decomposição

Mapeie o Domínio e Identifique Contextos
- Use técnicas de Domain-Driven Design para encontrar módulos coesos.
Selecione um Slice Iniciante
- Geralmente, escolher uma funcionalidade que gere alto valor e seja relativamente isolada para extrair como primeiro microserviço (ex.: serviço de “pagamento”).
Defina Contratos de Comunicação
- APIs REST, mensageria, schema de eventos. Planeje a interface que o microserviço exporá e que dados precisará consumir.
Implemente o Banco de Dados Local
- Mova as tabelas ou crie novas estruturas. Caso precise de dados de outro domínio, receba-os via evento ou chamada de API.
Estabeleça Observabilidade
- Configure logs, métricas e tracing distribuído para o novo microserviço, garantindo visibilidade do fluxo.
Teste Integrado
- Faça testes de ponta a ponta, garantindo que o microserviço responde e integra-se corretamente ao monólito remanescente.
Itere
- Repita com outros domínios. Com o tempo, o monólito vai encolhendo e sendo substituído por serviços independentes.

5. Principais Cuidados

Coesão de Domínio: Não quebre o monólito em serviços aleatórios; cada serviço deve refletir um subdomínio real de negócio.
Governança Forte de Dados: Estabeleça quem é o dono de cada entidade, como as atualizações serão propagadas e que modelo de consistência será adotado (forte, eventual etc.).
Simplicidade Inicial: Evite criar dezenas de serviços de uma só vez. Vá extraindo gradualmente, avaliando a maturidade da arquitetura de microserviços na organização.
Automação e Observabilidade: Microserviços geram overhead de CI/CD e monitoramento; estabeleça pipelines automáticos, logs e dashboards desde o início.

6. Conclusão

A decomposição de um monólito em microserviços exige uma análise criteriosa para definir onde e como separar os módulos, buscando um subdomínio coeso que ganhe autonomia sem fragmentar demais o sistema. A governança de dados é igualmente importante: cada microserviço mantém seu banco e é responsável (dono) pelos agregados que manipula, comunicando-se com outros serviços via APIs ou eventos.

Pontos-Chave:

Entender as fronteiras de domínio que justificam separar um serviço.
Garantir isolamento de dados: cada serviço cuida de suas entidades, sem acesso direto a tabelas de outro.
Determinar estratégias de comunicação (eventos, REST) e manter a consistência de forma clara (eventual ou mais próxima de ACID, quando viável).
Iniciar pequeno e expandir gradualmente, medindo o valor agregado por cada extração.

Com um processo iterativo, alinhado aos objetivos de negócio e ao domínio, a organização atinge uma arquitetura de microserviços sólida — preservando a coerência dos dados e a flexibilidade na evolução de cada parte do sistema.

Você já enfrentou desafios na hora de decompor o monólito? Compartilhe nos comentários suas experiências e as soluções que adotou!