Anderson LimaSoftware Engineer & Consultant
4 de octubre de 2026
19 min de lectura
66 visualizaciones
Monólito Modular vs. Microsserviços: Como Escolher sem Pagar Cedo pela Distribuição
English summary: A practical comparison of modular monoliths and microservices, with module contracts, extraction criteria, operational failure modes, cost, observability, security, incremental migration, and a decision checklist.
Published April 2026 Reading time: 18 min Keywords: monólito modular, microsserviços, arquitetura de software, DDD, observabilidade, migração incremental
Um time pequeno pode passar semanas discutindo como dividir o sistema em microsserviços e ainda não ter decidido quem é dono de um dado, de um contrato ou de um alerta. Enquanto isso, cada nova chamada de rede acrescenta um lugar para timeout, retry duplicado e incidente.
A tese deste artigo é simples: comece pela fronteira de negócio e pelo contrato; só crie uma fronteira de processo quando a independência operacional pagar o custo da distribuição. Um monólito modular não é uma desculpa para acoplamento. Microsserviços não são uma prova de maturidade. São duas formas de distribuir responsabilidades, com preços operacionais diferentes.
Um monólito modular é um único artefato implantável e, normalmente, um único processo, organizado em módulos que têm responsabilidades, dados e APIs internas explícitas. Os módulos podem compartilhar runtime e transações locais, mas não devem compartilhar qualquer detalhe por conveniência.
Microsserviços são componentes implantáveis e operáveis de forma independente. Cada serviço precisa ter uma capacidade de negócio coerente, um dono, um contrato de comunicação e autoridade sobre seus dados. Separar pastas, containers ou repositórios sem essa autonomia cria apenas um monólito distribuído.
| Dimensão | Monólito modular | Microsserviços |
|---|---|---|
| Fronteira principal | Módulo lógico dentro do processo | Processo, implantação e operação independentes |
| Comunicação | Chamada local ou evento interno | API, RPC ou mensageria pela rede |
| Dados | Pode haver banco compartilhado, mas com ownership por módulo | Cada serviço deve controlar seu armazenamento |
| Transação | Uma transação local pode cobrir módulos | Coordenação entre serviços exige saga, outbox ou consistência eventual |
| Escala | Escala a aplicação inteira, salvo particionamento interno | Escala cada serviço quando o perfil de carga justifica |
| Falha | Menos falhas de rede; risco de falha no processo inteiro | Isolamento possível, mas com falhas parciais e cascatas |
| Deploy | Simples de lançar, mais amplo em escopo | Independente, mas com mais pipelines, versões e gates |
O nome da arquitetura importa menos do que os invariantes. Um módulo com acesso às tabelas de outro módulo não é modular porque está em uma pasta bonita. Um serviço que precisa de cinco chamadas síncronas para responder não é independente porque tem um Deployment próprio.
Nem todo problema precisa de uma decisão arquitetural sofisticada. Um batch que lê dados, processa uma fila e grava um resultado pode ser um workflow simples. Uma aplicação CRUD com baixo volume pode permanecer em um monólito convencional enquanto o domínio é aprendido. O custo de introduzir fronteiras só se justifica quando existe uma mudança concreta: equipes precisam publicar separadamente, uma capacidade tem um perfil de escala muito diferente, uma falha precisa ser contida ou um requisito de isolamento é real.
Antes de vender uma arquitetura, procure os modos como o desenho atual falha. Eles mostram qual fronteira falta — e também se o problema é modularidade, operação ou apenas processo.
O sintoma é um caso de uso que lê diretamente a tabela de outro domínio, instancia seu serviço interno e altera o estado de três áreas sem contrato. A mudança parece local, mas exige conhecimento de todo o sistema.
// O problema não é estar no mesmo processo.
// O problema é atravessar a fronteira sem um contrato.
export async function createOrder(input: CreateOrderInput) {
const customer = await customerTable.findById(input.customerId);
await paymentService.charge(customer.cardNumber, input.total);
await inventoryTable.updateStock(input.items);
return orderTable.insert(input);
}
O resultado é acoplamento semântico, testes que precisam montar o sistema inteiro e ownership indefinido. Extrair esse código para três serviços não corrige o acoplamento; transforma imports em chamadas de rede.
Cada serviço é implantado separadamente, mas o fluxo de checkout exige uma cadeia síncrona de pedidos, clientes, preços, estoque e pagamentos. Um deploy precisa coordenar todos. Um timeout em qualquer elo bloqueia o usuário. O sistema ganhou a latência e a indisponibilidade da rede sem ganhar autonomia.
O alerta é uma frase como “não podemos atualizar este serviço sem atualizar os outros quatro”. Independência de deploy deve ser medida pelo fluxo real, não pelo número de manifests.
Quando vários componentes escrevem diretamente nas mesmas tabelas, o schema vira a API não versionada do sistema. Um índice, uma coluna renomeada ou uma mudança de semântica pode quebrar consumidores que ninguém conhece.
Um banco único pode ser uma decisão válida no monólito modular, desde que cada módulo tenha ownership explícito, acesso encapsulado e regras verificáveis. O problema não é a quantidade de instâncias de banco; é a autoridade sobre o dado.
A equipe sabe que o endpoint falhou, mas não sabe em qual módulo, contrato ou dependência. Logs não carregam trace_id, eventos não têm versão, métricas não distinguem checkout de catálogo e o custo de infraestrutura é somado sem atribuição.
Sem observabilidade, um microsserviço é uma unidade de implantação que pode falhar de forma mais difícil de explicar. Observabilidade deve existir antes da extração, para que a comparação tenha uma linha de base.
O objetivo não é prever todos os futuros serviços. É tornar explícito o que pode mudar junto e o que não pode atravessar uma fronteira sem permissão.
src/
├── modules/
│ ├── orders/
│ │ ├── domain/
│ │ ├── application/
│ │ ├── infrastructure/
│ │ └── public.ts
│ ├── payments/
│ │ ├── domain/
│ │ ├── application/
│ │ └── public.ts
│ ├── inventory/
│ │ └── public.ts
│ └── customers/
│ └── public.ts
├── platform/
│ ├── database/
│ ├── events/
│ └── observability/
└── app.ts
public.ts não deve exportar entidades, repositórios ou tabelas internas. Ele expõe comandos, consultas e eventos que representam a linguagem do módulo. Uma regra arquitetural pode impedir imports de modules/payments/domain a partir de modules/orders e permitir apenas modules/payments/public.
Neste exemplo, Orders depende de uma porta própria. A implementação pode chamar Payments no mesmo processo hoje e uma API amanhã, sem alterar o caso de uso. O exemplo usa um token de pagamento, não dados de cartão; autenticação, idempotência e persistência de outbox continuam sendo responsabilidades de produção.
// modules/orders/public.ts
export type OrderId = string & { readonly __brand: "OrderId" };
export type OrderCreatedV1 = {
type: "orders.order-created";
version: 1;
orderId: OrderId;
itemIds: string[];
occurredAt: string;
};
// A porta pertence ao módulo consumidor: Orders define o que precisa.
export interface PaymentPort {
authorize(input: {
orderId: OrderId;
amountInCents: number;
paymentToken: string;
idempotencyKey: string;
}): Promise<{ authorizationId: string; status: "authorized" | "declined" }>;
}
export interface OrdersPublicApi {
create(input: {
customerId: string;
itemIds: string[];
paymentToken: string;
}): Promise<{ orderId: OrderId; status: "pending" | "confirmed" }>;
}
// modules/orders/application/create-order.ts
import type { OrderId, OrdersPublicApi, PaymentPort } from "../public";
export function createOrdersApi(deps: {
payments: PaymentPort;
orders: { insert: (input: unknown) => Promise<{ id: string; totalInCents: number }> };
}): OrdersPublicApi {
return {
async create(input) {
const order = await deps.orders.insert(input);
const orderId = order.id as OrderId;
const payment = await deps.payments.authorize({
orderId,
amountInCents: order.totalInCents,
paymentToken: input.paymentToken,
idempotencyKey: `order:${order.id}`,
});
return {
orderId,
status: payment.status === "authorized" ? "confirmed" : "pending",
};
},
};
}
O contrato é útil apenas se houver regras para mantê-lo. Vale registrar, por módulo:
Eventos também são contratos. orders.order-created precisa de versão, identificador único, timestamp e política de evolução. Um event bus interno não elimina a necessidade de tratar duplicidade, ordenação e falha de handler; apenas torna esses problemas locais e mais baratos de testar.
Productos gratuitos y de pago para convertir ideas en una base que puedas lanzar.
13 productos disponibles
nextjs · boilerplate
Boilerplate de API em Python com FastAPI, organizado em Clean Architecture (router, service, repository e adapters por módulo). Inclui autenticação JWT com hashing bcrypt, MongoDB, testes com pytest e cobertura, Dockerfile e docker-compose para subir localmente, e documentação Swagger/OpenAPI automática. Repositório de origem privado; snapshot técnico verificado antes da publicação.
Ver producto
react · boilerplate
Base React Native para apps iOS y Android con Expo, Clean Architecture, MVVM, Firebase y módulos nativos. Referencia técnica de VaiDeFut, con distribución pública en Google Play y un flujo de publicación para iOS documentado.
Ver producto
nextjs · boilerplate
Kit gratuito y open source para comenzar con agentes de código en Claude Code, Codex, Gemini, Copilot y OpenCode. El repositorio público confirma una licencia MIT.
Ver producto
nextjs · boilerplate
Base AI-first white-label para lanzar productos SaaS con Next.js, chat, RAG, memoria, tenants y documentación. El snapshot verificado documenta Supabase, no MongoDB; la limitación está explícita. MongoDB, Redis y RabbitMQ requieren una integración/configuración compatible.
Ver producto
nextjs · boilerplate
Edición avanzada de una base white-label y multi-tenant AI-first para acelerar productos con Next.js, chat, RAG, memoria y documentación. El snapshot verificado no demuestra una capa Ultra distinta; la limitación y los cambios de provider, cache y colas quedan transparentes.
Ver producto
nextjs · boilerplate
Base white-label y multi-tenant para convertir una idea en un SaaS AI-first con Next.js, chat, RAG, memoria y seguridad documentada. El snapshot verificado usa Supabase; el nombre identifica el repositorio de origen. Los límites de provider, cache y colas son explícitos; Redis y RabbitMQ son integraciones configurables.
Ver producto
react · portfolio
Una contribución única para apoyar contenido técnico gratuito, investigación y la continuidad de proyectos relevantes publicados por Anderson Lima. Tú eliges el valor; no es una suscripción.
Ver producto
react · boilerplate
Starter React gratuito para crear una suite de pruebas confiable desde el primer commit con Vitest, Testing Library, Playwright, Vite, TypeScript, Zustand, React Query, MirageJS y PWA. El repositorio no declara una licencia SPDX; revisa sus términos antes del uso comercial.
Ver producto
react · portfolio
Monorepo público en React, TypeScript y Vite para explorar una biblioteca de componentes con lenguaje visual inspirado en interfaces nativas. El README actual es breve y no declara una licencia SPDX; trátalo como preview gratuito.
Ver producto
nextjs · saas
Boilerplate SaaS AI-first con Next.js, Supabase, Stripe y provider routing para avanzar desde el primer prompt hasta un despliegue real más rápido. Los cambios de IA, datos, email, cache y colas son explícitos; Redis y RabbitMQ son integraciones configurables.
Ver producto
react · saas
Starter React + TypeScript para SaaS multi-tenant con Firebase, Atomic Design, temas, PWA, pantallas de producto, MirageJS y chat Gemini extensible a otros providers. Valida requisitos de producción, costes e integraciones antes de publicar.
Ver producto
react · boilerplate
Starter React público con TypeScript, Zustand, React Query, Tailwind CSS, PWA e integraciones de IA documentadas. El repositorio no declara una licencia SPDX; revisa sus términos antes del uso comercial.
Ver producto
nextjs · saas
Landing SaaS para Next.js, TypeScript y Tailwind CSS con SEO, temas, i18n, PWA y puntos de integración para auth, Stripe e IA. Una base clara para dejar atrás la pantalla en blanco y dar forma a tu propuesta.
Ver productoContinúa explorando temas similares
React nasceu para resolver a camada de interface, não para definir a aplicação inteira. Isso explica o surgimento de Next.js, Remix, Vite e todo o ecossistema em volta do React. Este artigo mostra por que essa distinção entre biblioteca e framework continua relevante, quais trade-offs ela cria e quando faz sentido usar React puro ou um meta-framework.
A IA não vai substituir programadores, mas vai extinguir o cargo de 'Sênior' como o conhecemos. Descubra por que a codificação braçal perdeu valor e como a arquitetura de sistemas se tornou a única competência à prova de futuro. Um manifesto para a nova era da engenharia.
# Por Que Seus Agentes de IA Continuam Falhando (E Como Consertar) Você gastou 3 meses construindo agentes de IA. Funcionaram lindamente nas demos. Em produção, são um desastre. A
Un checklist práctico para validar seguridad, costos, evaluaciones y observabilidad antes de llevar tu app con IA a producción.
Templates probados en producción, usados por desarrolladores. Ahorra semanas de setup en tu próximo proyecto.
Microsserviços não são “módulos melhores”. São uma mudança de unidade de falha, deploy, identidade, dados e operação. A orientação da Microsoft destaca exatamente os custos que aparecem quando a decomposição é tratada só como divisão de código: consistência de dados, versionamento, latência, testes de dependências, logging correlacionado e necessidade de maturidade DevOps.
| Aspecto | Monólito modular | Microsserviços |
|---|---|---|
| Transação de checkout | Uma transação local é possível quando o domínio permite | Normalmente exige saga, compensação ou consistência eventual |
| Latência | Chamada de função e acesso local | Serialização, rede, balanceamento e retries entram no caminho |
| Isolamento | Um bug pode derrubar o processo inteiro | Um serviço pode falhar isoladamente, mas a dependência pode propagar a falha |
| Debug | Stack trace e estado mais próximos | Logs, traces e versões precisam ser correlacionados |
| Escala | Simples, porém mais ampla | Granular, com custo de provisionamento e coordenação |
| Schema | Migrações coordenadas em um app | Contratos e migrações backward-compatible por serviço |
| Time | Menor carga de plataforma | Cada equipe precisa operar seu serviço de ponta a ponta |
| Custo | Menos componentes e menor custo fixo | Mais compute, rede, pipelines, ambientes, suporte e on-call |
A vantagem de escala independente é real quando a carga, o perfil de recursos ou a disponibilidade de um domínio são significativamente diferentes. Se Orders e Inventory sempre escalam juntos, separá-los adiciona uma fronteira sem comprar capacidade útil.
Uma função local falha de um jeito. Uma chamada remota pode expirar, ser executada e perder a resposta, ser repetida, retornar uma versão incompatível ou encontrar um serviço parcialmente saudável.
| Falha | Sintoma | Controle mínimo |
|---|---|---|
| Timeout em cadeia | p95 cresce e threads ficam ocupadas esperando | timeouts por chamada, deadline propagado e bulkhead |
| Retry duplicado | cobrança ou comando acontece mais de uma vez | idempotency key, deduplicação e retry com orçamento |
| Falha parcial | pedido criado, pagamento desconhecido | estado explícito, outbox e reconciliação |
| Schema incompatível | consumidor quebra após deploy | expand-and-contract, compatibilidade e contrato em CI |
| Cascata | uma dependência derruba várias APIs | circuit breaker, fallback honesto e limites de concorrência |
| Deploy divergente | versões incompatíveis convivem | rollout gradual, health check e rollback testado |
| Mensagem perdida ou duplicada | projeção fica desatualizada | outbox/inbox, replay seguro e métrica de lag |
Retries não são uma política de disponibilidade por si só. Eles aumentam carga justamente quando a dependência está sob pressão. Toda política precisa de limite, jitter, idempotência e uma resposta clara para o caso em que o resultado é desconhecido.
O custo de um serviço não é apenas a CPU do container. Uma conta útil precisa considerar:
custo_total = compute
+ banco_e_storage
+ rede_e_egress
+ pipelines_e_ambientes
+ plataforma_e_on_call
+ custo_de_migração
O monólito modular costuma ter custo fixo menor: menos imagens, dashboards, certificados, filas, regras de rede e ambientes para manter. Seu custo oculto aparece quando um módulo pesado força a escala da aplicação inteira ou quando um deploy amplo aumenta a janela de risco.
Microsserviços podem reduzir custo variável ao escalar um consumidor específico, mas acrescentam custo fixo e cognitivo. Se a equipe não consegue atribuir custo por serviço, ambiente e operação, “escala independente” é uma hipótese, não uma economia comprovada.
request_id, trace_id, módulo, operação, versão e resultado;event_id, correlation_id, versão, produtor, consumidor e timestamp;No monólito, tracear módulos internos evita que “um processo saudável” esconda um módulo degradado. Em microsserviços, o trace precisa atravessar a rede e sobreviver a retries. OpenTelemetry fornece o modelo de traces, spans e contexto; a escolha do backend não substitui a definição de quais jornadas importam.
Um monólito modular pode ter isolamento de autorização, ownership de dados e limites de segredo. Um microsserviço pode compartilhar uma credencial administrativa, aceitar tráfego de qualquer origem e expor PII demais. O processo de deploy não é um boundary de segurança automaticamente.
| Risco | Monólito modular | Microsserviços |
|---|---|---|
| Acesso a dados | limitar queries ao módulo e à identidade da aplicação | identidade por serviço, banco privado e política de rede |
| Autorização | validar actor e recurso na API do módulo | autenticação mútua, autorização no serviço e gateway apenas como camada adicional |
| Segredos | escopo por ambiente e rotação | escopo por serviço, rotação e nenhum segredo em payload/log |
| PII | minimizar campos no contrato interno | minimizar payloads, criptografar trânsito e controlar cópias em filas |
| Auditoria | evento de decisão com ator e motivo | trilha correlacionada entre serviços, sem registrar dados sensíveis |
| Falha | limitar blast radius do processo e do banco | limitar egress, namespaces, permissões e confiança entre serviços |
Use o princípio do menor privilégio, autenticação entre workloads e validação de entrada em toda fronteira. A OWASP Microservices Security Cheat Sheet é uma referência prática para threat modeling, identidade, secrets, comunicação e logging. Se o requisito é isolamento regulatório ou de dados, escreva qual isolamento é exigido — processo, conta, região, chave, banco ou operador — antes de concluir que microsserviços resolvem o problema.
O tamanho do diretório, a quantidade de classes e o desejo de “ter escala” são sinais fracos. Extraia quando a fronteira já for compreendida e a independência resolver um custo mensurável.
Um candidato forte costuma satisfazer a maior parte destes critérios:
Extração é uma decisão de produto e operação tanto quanto de código. Se o único argumento é “o módulo tem muitas linhas”, modularize dentro do monólito e meça antes.
Use esta tabela como uma conversa com evidências, não como uma pontuação automática. Marque a coluna que descreve o problema real e registre um link para métrica, incidente, contrato ou requisito.
| Situação observada | Fique no monólito modular | Extraia um serviço | Comece distribuído |
|---|---|---|---|
| Produto e domínio | regras mudam rapidamente; fronteiras ainda estão sendo aprendidas | um bounded context já tem linguagem e ownership próprios | contextos e restrições são conhecidos antes do primeiro deploy |
| Times | uma equipe ou poucas equipes coordenadas | equipe dedicada com on-call e SLO | várias equipes realmente independentes desde o início |
| Escala | cargas semelhantes e moderadas | um domínio tem perfil de carga muito diferente | escala, disponibilidade ou isolamento são requisitos conhecidos |
| Dados | transações locais simplificam o negócio | ownership pode ser separado sem escrita cruzada | autonomia de dados é requisito desde o desenho inicial |
| Operação | não há plataforma, tracing e plantão maduros | plataforma e runbooks estão prontos para o candidato | operação distribuída é competência existente, não promessa |
| Segurança/compliance | isolamento lógico atende ao requisito | um boundary específico reduz o blast radius | segregação física ou de identidade é obrigatória e documentada |
| Evidência de sucesso | menor lead time e menos acoplamento de módulos | deploy, escala ou falha melhoram de forma mensurável | o risco de não distribuir é maior que o custo operacional |
Regra de desempate: escolha o desenho que preserva mais opções com o menor custo de reversão. Um monólito modular com contratos permite extrair depois. Um conjunto de serviços mal delimitados acumula decisões distribuídas difíceis de desfazer.
Migração segura não é copiar uma pasta para outro repositório. É substituir uma implementação atrás de um contrato, mantendo uma única autoridade para cada efeito.
Mapeie chamadas, tabelas, eventos, usuários, SLOs, custos e incidentes do módulo. Crie testes de contrato e uma regra que impeça novas dependências internas. A Spring Modulith é um exemplo de tooling que valida a estrutura, documenta módulos e observa interações em aplicações Spring; o princípio vale em qualquer stack.
Escolha o dono de cada tabela ou agregado. Troque acesso direto por uma API interna. Se outros módulos precisam de informação, publique uma consulta ou uma projeção; não entregue um repositório compartilhado como atalho permanente.
Use compatibilidade expand-and-contract: adicione o novo campo, migre consumidores, observe, só então remova o antigo. Para eventos, aceite duplicidade e reprocessamento. Para efeitos externos, use idempotência. Para publicar junto com uma mudança de banco, considere outbox transacional.
O caso de uso continua dependendo da porta. Em produção, um flag de roteamento pode enviar uma parcela controlada para a implementação remota, mas não deve criar dois escritores concorrentes do mesmo estado.
const payments: PaymentPort = flags.remotePayments
? new HttpPaymentAdapter({ baseUrl: env.PAYMENTS_URL, auth: serviceIdentity })
: new LocalPaymentAdapter({ paymentGateway, outbox });
const orders = createOrdersApi({ payments, orders: orderRepository });
O adaptador HTTP precisa de timeout, deadline, autenticação, validação de resposta, retry limitado e uma estratégia para “resultado desconhecido”. fetch() sozinho não é um desenho de resiliência.
Suba o novo serviço com o contrato já exercitado. Faça canary ou roteamento gradual, compare erros, latência, custo e resultados de negócio. Quando o caminho remoto for a autoridade, remova a implementação local, as permissões antigas e as métricas que não têm mais dono.
Esse padrão é compatível com o Strangler Fig da AWS: substituir partes do monólito progressivamente, com uma interface que reduz risco e interrupção. O padrão não autoriza manter duas fontes de verdade indefinidamente.
Toda escolha precisa de um harness: o conjunto de contexto, ferramentas, permissões, ambiente, verificação e observabilidade que torna o sistema operável. O monólito modular tem um harness menor; microsserviços exigem que ele seja distribuído e versionado.
| Elemento | Pergunta | Evidência mínima |
|---|---|---|
| Contexto | Qual domínio e fluxo estamos mudando? | mapa de dependências, ADR e contrato |
| Ferramentas | Como construir, testar e operar? | pipeline, CLI/runbook, migrações reproduzíveis |
| Permissões | Quem pode ler, escrever, publicar e extrair? | IAM, ownership de schema e aprovação de mudança |
| Ambiente | Em qual runtime, região e dependência isso roda? | configuração versionada e paridade suficiente |
| Verificação | Como saberemos que a troca funcionou? | testes, contrato, canary, métricas e critério de rollback |
| Observabilidade | Como localizar uma falha e atribuir custo? | logs, traces, métricas, alertas e dashboard de jornada |
O OpenTelemetry pode padronizar sinais, mas não decide quais eventos são relevantes. A equipe precisa nomear o fluxo crítico, o dono do alerta e a ação de recuperação. Sem isso, adicionar um collector apenas produz mais dados.
Monólito modular e microsserviços são pontos diferentes no espaço de fronteiras. O primeiro concentra o runtime para reduzir complexidade de rede; o segundo paga complexidade distribuída para comprar independência operacional onde ela tem valor.
A decisão madura não pergunta “qual arquitetura escala mais?”. Pergunta: qual fronteira de negócio já é compreendida, qual custo ela elimina e qual operação a equipe consegue provar que sustenta?
Comece modular quando o domínio ainda está sendo descoberto. Faça contratos e ownership valerem dentro do processo. Extraia um módulo quando sua escala, ciclo de release, disponibilidade, segurança ou responsabilidade justificarem um processo próprio. E trate cada extração como uma mudança reversível, observável e com uma única fonte de verdade.