Microserviços ou Só Dor de Cabeça Distribuída? O Dilema da Dependência que Arrebenta Times

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 pedido

Esse 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! 😉