Onde o Dev Se Queima: O Mito do Microserviço Imaculado
Microserviços entraram no hype como a bala de prata do século. O problema? A maioria dos times adotou isso como religião, não como estratégia. **O mito do microserviço perfeito nasce quando o time acha que fragmentar o monolito é sinônimo de evoluir.**
Na prática, o que acontece é:
- explosão de deploys independentes (que nunca são tão independentes assim),
- dívida técnica distribuída em N repositórios,
- debug que atravessa rede, fila, gateway e meia dúzia de logs,
- dependências acopladas por eventos “soltos” que ninguém mais consegue explicar.
DHH já falou sobre a romantização dos microserviços — até equipes gigantes, como Netflix, reviram excessos. Esse mito só continua vivo porque alimenta um desejo infantil de “arquitetura pura” que não existe nos negócios reais.
Como Resolver Sem Gourmetização: Arquitetura Orientada ao Contexto de Negócio
Não escolha microserviços — escolha limites. **Microserviço é uma consequência, não um objetivo.**
A abordagem pragmática é simples:
- Identifique fronteiras de negócio (Bounded Contexts).
- Modele primeiro no monolito com módulos autônomos.
- Extraia serviços só quando há motivos reais: escala, deploy independente, autonomia de time.
- Evite message brokers como muletas — evento é contrato, não gambiarra distribuída.
Como lembra o artigo “A sua ‘Boa Prática’ é o Tradeoff de Alguém”, toda estratégia tem custo — e usar Kafka/RabbitMQ sem necessidade cria mais ruído que valor.
Implementação de Senior: Um Corte Bem Feito no Monolito
Se for extrair um microserviço, extraia direito. Nada de criar serviços “fantasmas” que só replicam tabela ou só viram proxy de outro. Abaixo, um exemplo realista usando FastAPI, com OpenAPI funcional desde o início — contrato antes do código.
from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI(
title="Order Pricing Service",
description="Serviço isolado para cálculo de preços",
version="1.0.0"
)
class PriceRequest(BaseModel):
product_id: str
quantity: int
class PriceResponse(BaseModel):
total: float
currency: str = "BRL"
@app.post("/calculate", response_model=PriceResponse)
def calculate_price(payload: PriceRequest):
base_price = consulta_preco(payload.product_id)
total = base_price * payload.quantity
return PriceResponse(total=total)
# OpenAPI 100% automático — contrato garantido.
Esse serviço sozinho existe porque existe uma necessidade clara: cálculo de preço é um domínio separado, com regras que mudam rápido e precisam de deploy autônomo. Isso é extração com propósito — não fetiche arquitetural.
O Preço da Escolha: O Custo de Microserviços e o Custo de Não Usá-los
Optar por microserviços custa:
- infra mais cara,
- observabilidade obrigatória,
- contratos rígidos,
- pessoas mais experientes,
- mais risco de erros distribuídos.
Não usar microserviços também custa:
- monolitos que travam releases,
- equipes grandes concorrendo no mesmo código,
- escala do sistema inteira amarrada.
Ou seja: não existe resposta perfeita. Só existe contexto.
Direto das Trincheiras
- Se um serviço novo precisa de quatro outros para funcionar, ele ainda é parte do monolito — só que distribuído.
- Design de eventos sem versionamento vira a nova “tabela legado” — mas espalhada pela empresa.
- Microserviço bom é aquele que você consegue reescrever em uma semana se der ruim.
Fontes Utilizadas
Artigo do DHH sobre a recuperação de microserviços : r/ruby,
A sua “Boa Prática” é o Tradeoff de Alguém – DEV Community
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 sistema distribuído. Não deixe de conferir outros artigos no blog reymaster.dev.br, onde continuamos desmontando hypes com pragmatismo.
Valeu e até a próxima! 😉
