Quando a Arquitetura Vira Armadilha: A Dor da Dependência Invisível
O erro não começa no Kubernetes. Começa na pressa. O time decide quebrar tudo em microserviços sem conhecer o contexto de negócio e sem prever que cada pedacinho vai precisar conversar com outro pedacinho — o tempo todo.
Resultado: você cria uma rede de serviços que dependem uns dos outros como se fossem um monólito… só que agora com latência, falhas distribuídas e aquele pesadelo chamado “debug por mensageria”.
Quando a dependência cresce, nasce o monólito distribuído: difícil de testar, difícil de versionar e impossível de entender sem rezar um pouco antes.
A Arquitetura que Funciona: Priorize Domínios, Não Hype
Microserviço só presta quando o domínio é independente. Se você precisa sincronizar estado o tempo todo, você não tem microserviços. Você tem problemas.
Por isso, a solução pragmática é simples: comece com um monólito modular. Só extraia microserviços quando:
- o módulo é realmente autônomo;
- o time tem maturidade de observabilidade;
- há clareza sobre limites de domínio;
- a escalabilidade exige isolamento real.
Menos glamour. Mais entrega.
Implementação de Sênior: Módulos Claros e uma Extração Segura
Um microserviço saudável nasce de um módulo limpo. Exemplo prático em FastAPI, simulando a extração de um módulo de “Pedidos” para um serviço independente:
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
app = FastAPI(title="Pedidos Service")
class Pedido(BaseModel):
id: int
cliente_id: int
valor: float
fake_db = {}
@app.post("/pedidos")
def criar_pedido(pedido: Pedido):
if pedido.id in fake_db:
raise HTTPException(status_code=400, detail="Pedido já existe")
fake_db[pedido.id] = pedido
return {"status": "ok", "pedido": pedido}
@app.get("/pedidos/{pedido_id}")
def obter_pedido(pedido_id: int):
pedido = fake_db.get(pedido_id)
if not pedido:
raise HTTPException(status_code=404, detail="Pedido não encontrado")
return pedidoEsse serviço só faz uma coisa: gerencia pedidos. Não consulta estoque, não valida pagamento, não tenta ser um mini ERP. Serviços pequenos evitam dependências tóxicas.
O Preço das Escolhas: Simplificar ou se Enterrar
Se você insiste em microserviços cedo demais:
- mais infraestrutura;
- mais latência;
- mais risco de falhas em cascata;
- mais gasto com observabilidade e tracing.
Se você fica no monólito pra sempre:
- cresce a dificuldade de escalar partes específicas;
- o deploy continua único e arriscado;
- pode criar gargalos que seriam resolvidos com isolamento.
No fim, a maturidade não está no estilo arquitetural, mas na capacidade de tomar decisões conscientes.
Direto das Trincheiras
- Não quebre nada sem mapear o domínio: CDD (Domain-Driven Design) não é modinha, é defesa contra caos.
- Não extraia serviço por tamanho, extraia por autonomia.
- Infraestrutura não salva má arquitetura. Kubernetes não conserta acoplamento.
Fontes
Monólitos Modulares: Uma Boa Escolha? : r/dotnet – Reddit,
Quando Microserviços Se Revelam Monólitos Distribuídos,
Flask, Django ou FastAPI? : r/Python – Reddit
Obrigado por acompanhar essa reflexão até o fim!
Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog, onde descascamos outros hypes da nossa área.
Valeu e até a próxima! 😉
