Monolito, Arquitetura em Camadas e Microsserviços

A maioria dos sistemas começa como um monólito. E não tem problema algum nisso. O problema é quando o monólito cresce sem nenhuma organização interna, e o time começa a gastar mais tempo desvendando dependências ocultas do que entregando funcionalidades.

Este post cobre a evolução natural das arquiteturas de software — do monólito para a arquitetura em camadas e, em determinados contextos, para microsserviços — com ênfase nos trade-offs reais de cada abordagem.

Visão Geral

• Monólito: uma aplicação única, um deploy para tudo.
• Arquitetura em Camadas: organização interna em camadas (UI, aplicação, domínio, infra) — ainda um único deploy.
• Microsserviços: várias aplicações pequenas e independentes, comunicando-se via APIs ou eventos.

1. Monólito

Uma aplicação única, com todas as funcionalidades, que roda e é implantada como um bloco só.

Quando usar

• Produtos em fase inicial.
• Equipes pequenas.
• Domínio ainda pouco definido.

Vantagens

• Simples de desenvolver, testar e implantar.
• Transações ACID fáceis (um único banco).
• Performance interna (chamadas em memória, sem latência de rede).
• Custos operacionais menores no início.

Desafios

• Acoplamento crescente — evolução fica difícil com o tempo.
• Deploy único significa risco alto: qualquer mudança afeta o sistema inteiro.
• Escalabilidade desigual — para escalar um módulo, escala tudo junto.
• Sem estrutura interna, vira o famoso Big Ball of Mud.

Boas práticas

• Organizar em módulos separados (Monólito Modular).
• Usar camadas bem definidas (UI, domínio, infra).
• Aplicar DDD leve (entidades, serviços de domínio).
• Adotar CI/CD e feature flags para reduzir risco nos deploys.

2. Arquitetura em Camadas (Layered)

Estilo de organização interna que pode ser aplicado tanto em monólitos quanto em microsserviços. Não é um tipo de deploy — é uma forma de estruturar o código.

Camadas típicas

1. Apresentação (UI/API): controllers, validações, DTOs.
2. Aplicação/Serviços: orquestra casos de uso.
3. Domínio (Core): entidades, regras de negócio, policies.
4. Infraestrutura: persistência, mensageria, APIs externas.

Benefícios

• Separação de responsabilidades clara.
• Testabilidade alta — cada camada pode ser testada de forma isolada.
• Evolução mais segura — mudanças ficam contidas na camada correta.

Cuidados

• Evitar modelo anêmico (entidades sem lógica, só getters/setters).
• Respeitar a direção de dependências: UI → App → Domínio → Infra.
• Não deixar detalhes de infraestrutura vazar para o domínio.

3. Microsserviços

Conjunto de serviços pequenos e autônomos, cada um dono do próprio banco e alinhado a um subdomínio de negócio específico.

Quando faz sentido

• Domínio já estável e bem mapeado.
• Necessidade de escala granular (diferentes partes do sistema têm cargas diferentes).
• Múltiplas equipes (squads) precisam trabalhar de forma autônoma.
• Deploys independentes e resiliência a falhas são prioridade.

Vantagens

• Escala por serviço — paga pela infraestrutura do que precisa.
• Deploy independente — atualiza um serviço sem afetar os outros.
• Autonomia de tecnologia — cada serviço pode usar a stack mais adequada.
• Resiliência a falhas locais — um serviço caindo não derruba o sistema todo.

Desafios

• Complexidade distribuída — rede, latência, retries, timeouts.
• Dados distribuídos — consistência eventual em vez de ACID.
• Observabilidade — logs, métricas e tracing distribuído são obrigatórios.
• Governança — versionamento de contratos e APIs.
• Custos operacionais maiores (mais infraestrutura, mais orquestração).

Boas práticas

• Definir Bounded Contexts (DDD) antes de cortar serviços.
• Um banco por serviço — nunca banco compartilhado.
• Preferir comunicação assíncrona (eventos, filas) para desacoplamento.
• Usar contratos versionados.
• Implementar padrões de resiliência: circuit breaker, timeout, retries.
• Adotar OpenTelemetry e tracing distribuído desde o início.

4. Comparativo

5. Estratégias de Migração

Migrar de monólito para microsserviços não é um projeto de fim de semana. As estratégias mais usadas:

• Strangler Fig: cercar o monólito e extrair features aos poucos, sem interrupção.
• Modularizar internamente antes de separar em serviços.
• Usar Anticorruption Layer para integrar com sistemas legados sem contaminar o domínio novo.
• Definir estratégia de dados (sagas, eventos) antes de separar os bancos.
• Começar pelos hotspots — módulos com mais dor de escala ou frequência de mudança.

6. Banco de Dados em Microsserviços

SQL (Relacional)

Bancos como PostgreSQL, MySQL e SQL Server são ideais para sistemas que exigem integridade transacional.

• Transações ACID — Atomicidade, Consistência, Isolamento e Durabilidade.
• Consultas complexas com JOIN, agregações e filtros avançados.
• Integridade referencial assegurada por chaves e restrições.

Quando usar: pagamentos, pedidos, autenticação — qualquer fluxo onde a consistência forte é inegociável.

NoSQL (Não Relacional)

Bancos como MongoDB, Cassandra e Redis oferecem flexibilidade e escalam bem em ambientes distribuídos.

• Flexibilidade de esquema — sem estrutura fixa de tabelas.
• Escalabilidade horizontal — adiciona nós conforme o volume cresce.
• Consistência eventual, priorizando disponibilidade e desempenho.

Quando usar: catálogos de produtos, sessões, dados de IoT, histórico de eventos.

Teorema CAP

Todo sistema distribuído precisa escolher entre duas das três propriedades:

Bancos SQL priorizam Consistência + Disponibilidade. Bancos NoSQL priorizam Disponibilidade + Particionamento, aceitando consistência eventual.

Padrões para dados distribuídos

Database per Service — cada microsserviço tem seu próprio banco. Nunca banco compartilhado entre domínios. Isso garante autonomia de deploy e escala independente.

CQRS (Command Query Responsibility Segregation) — separa as operações de escrita (commands) das de leitura (queries). Permite otimizações específicas para cada tipo: banco relacional para escrita, Elasticsearch para leitura, por exemplo.

Event Sourcing — cada mudança de estado é registrada como um evento imutável. A aplicação reconstrói seu estado a partir desses eventos. Garante rastreabilidade total e histórico auditável.

Sagas — coordenam transações distribuídas usando eventos assíncronos. Cada etapa tem uma ação compensatória caso algo falhe, garantindo consistência eventual sem bloqueios distribuídos (2PC).

7. Comunicação entre Microsserviços

A forma como os serviços se comunicam define a qualidade do sistema inteiro. Existem três modelos principais.

Comunicação Síncrona (REST / gRPC)

O cliente faz uma requisição e espera pela resposta. É o modelo clássico — simples, direto e previsível.

REST / HTTP é o mais comum. Simples de implementar, bem suportado em qualquer linguagem, mas cria acoplamento temporal: se o servidor cai, o cliente também quebra.

gRPC é mais moderno e performático. Usa serialização binária (Protocol Buffers), suporta streams bidirecionais e define contratos fortemente tipados. Mais rápido que JSON/REST e ideal para comunicação interna entre microsserviços. A desvantagem é a complexidade maior e dificuldade de expor diretamente para o frontend.

Quando usar: operações críticas em tempo real onde a resposta importa imediatamente — consultas de saldo, validação de pagamento, autenticação.

Comunicação Assíncrona (Kafka / RabbitMQ)

O cliente envia uma mensagem e não espera resposta. O servidor processa quando puder, usando filas ou streams.

Tecnologias: Kafka, RabbitMQ, AWS SQS, NATS, Pulsar.

Vantagens: desacoplamento temporal, alta resiliência, absorve picos de tráfego. Se um consumidor cai, as mensagens ficam na fila até ele voltar.

Desafios: exige infraestrutura de broker, tratamento de retries, deduplicação e Dead Letter Queue (DLQ). Debug mais complexo — tracing distribuído é obrigatório.

Quando usar: propagação de eventos, notificações, processamento em background — qualquer fluxo onde o produtor não precisa esperar o resultado.

API Gateway

Um ponto único de entrada que recebe, roteia e controla as requisições para os microsserviços internos. Exemplos: Kong, Traefik, Apigee, Amazon API Gateway.

O gateway centraliza: autenticação e autorização, rate limiting, transformação de payloads, métricas e observabilidade.

O risco é virar um ponto único de falha — precisa de alta disponibilidade e bom monitoramento.

Padrão híbrido (REST + Mensageria)

Na prática, os sistemas saudáveis usam os dois modelos:

• REST/gRPC para operações rápidas e críticas que precisam de resposta imediata.
• Kafka/RabbitMQ para propagação de eventos e processamento assíncrono.

Exemplo: pedido criado via REST → evento PedidoCriado publicado no Kafka → estoque, faturamento e notificação consomem de forma independente.

8. Anti-padrões

• Banco de dados compartilhado entre serviços (o maior assassino de autonomia).
• Nanosserviços — fragmentação excessiva sem justificativa de negócio.
• Comunicação síncrona em cascata — A chama B que chama C que chama D. Um nó lento trava toda a cadeia.
• Migração “big bang” — tentar migrar tudo de uma vez.
• Serviços sem CI/CD e sem observabilidade.

9. Quando Migrar para Microsserviços

Manter o Monólito se

• O time é pequeno.
• O produto está no início.
• A escalabilidade é resolvível com cache/CDN.
• Deploys menos frequentes são aceitáveis.

Migrar para Microsserviços se

• O contexto de negócio está bem delimitado e estável.
• Existe dor real de escala ou necessidade de releases independentes.
• O plano de observabilidade e dados está definido.
• A estratégia de contratos e versionamento está estabelecida.

Conclusão

Comece com monólito modular em camadas. Organize o código internamente, defina bounded contexts, mantenha boa cobertura de testes. Evolua para microsserviços onde realmente existe dor — escala, autonomia de equipe, deploys independentes.

A tendência do mercado não é escolher um modelo e ficar nele para sempre. É entender que cada parte do sistema pode ter uma arquitetura diferente, e que a decisão certa depende da maturidade do domínio, do tamanho do time e da carga real.

Arquitetura é sobre trade-offs. Toda escolha tem custo. A pergunta não é “qual é a melhor arquitetura?”, mas “qual é a melhor arquitetura para esse contexto, agora?”.

Referências

• Martin Fowler — Microservices
• Martin Fowler — Strangler Fig Application
• CAP Theorem — Eric Brewer
• CQRS — Martin Fowler
• Saga Pattern — microservices.io
• gRPC — Documentação Oficial
• OpenTelemetry — Documentação Oficial