A Dor Real: Quando Dividir Vira Multiplicar Problema
O romance dos microserviços acaba rápido quando a explosão de serviços vira uma explosão de dependências, latência, debugging impossível e deploys amarrados. Quem vive nas trincheiras sabe: microserviço demais vira monolito distribuído, e monolito distribuído é dor amplificada.
O grande erro? Migrar para microserviços sem entender o contexto de negócio. Em vez de isolar responsabilidades, muita equipe só quebra o monolito em caquinhos — cada um com sua stack própria, sua pipeline própria e seu drama próprio.
Solução Pragmática: Microserviços Só Onde Existe Fricção de Verdade
A regra é simples: só existe microserviço quando existe fronteira clara de domínio. Se não há autonomia de deploy, time responsável e dados bem delimitados, você não tem microserviço — tem um pseudo-serviço pendurado em outro.
Use microserviços para:
- Domínios que evoluem em velocidades diferentes
- Áreas onde a escala é desigual
- Funcionalidades que exigem isolamento de falha
O resto deveria continuar no bom e velho monolito modular.
Implementação de Sênior: Um Corte Limpo de Domínio com OpenAPI
A seguir, um exemplo realista de como definir a fronteira de um domínio para virar microserviço sem criar mais caos do que solução. Aqui o contrato é o rei — OpenAPI primeiro, código depois.
openapi: 3.1.0
info:
title: Billing Service API
version: 1.0.0
paths:
/charges:
post:
summary: Cria uma cobrança
tags:
- Billing
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateChargeRequest'
responses:
'201':
description: Cobrança criada
content:
application/json:
schema:
$ref: '#/components/schemas/ChargeResponse'
components:
schemas:
CreateChargeRequest:
type: object
properties:
userId:
type: string
amount:
type: number
currency:
type: string
ChargeResponse:
type: object
properties:
chargeId:
type: string
status:
type: string
enum: [CREATED, FAILED]Um contrato simples, claro e isolado. Billing não sabe nada de User. User não sabe nada de Billing. Cada um evolui no seu ritmo. Isso é microserviço de verdade: domínio antes da tecnologia.
Direto das Trincheiras
- Se dois serviços precisam conversar mais de três vezes por request, junte-os.
- Evite filas como curativo para design ruim — mensageria não salva domínio mal cortado.
- Autonomia não é um ideal abstrato: se você não consegue deployar sem sincronizar com outro time, aquilo não é microserviço.
O Custo da Escolha: O Preço de Distribuir Tudo (ou de Não Distribuir Nada)
Microserviços têm custo: observabilidade, tracing, segurança distribuída, CI/CD isolado, versionamento de contrato, resiliência. É arquitetura para adultos, não para quem busca hype. O monolito, por outro lado, cobra ao longo do tempo se crescer sem modularidade — vira um pântano onde ninguém mexe sem quebrar algo.
O ponto é simples: não existe bala de prata. Existe contexto e trade-off consciente.
Fontes
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 descasquemos outros ‘hypes’ da nossa área.
Valeu e até a próxima! 😉
