Monolito vs. microserviços
TLDR
Monolito: um aplicativo grande que faz muita coisa (cadastro, pedidos, pagamento, relatórios) num “bloco” só. “Mudar um campo” pode ser mais barato em número de sistemas, mas o código pode ser difícil de mexer (débito técnico). Microserviços: vários pedacinhos (cada um com uma responsabilidade) que “conversam” entre si pela rede. “Mudar um campo” pode envolver vários times e várias atualizações. Híbrido: parte no sistema grande, parte nos pedacinhos. Saber em que cenário você está para aquela feature define o tipo de pergunta e de promessa que faz sentido fazer.
Por que isso importa
“Mudar um campo” pode ser rápido em um contexto e um projeto inteiro em outro. Fazer as perguntas certas evita promessa errada: essa feature roda no sistema grande (monolito) ou nos serviços? Quantos times ou sistemas tocam nessa jornada?
Conceito (em linguagem simples)
- Monolito: Um deploy, uma base de código (ou poucas). Tudo “dentro do mesmo bloco”. Integração é “interna”; o desafio costuma ser código antigo e difícil de mexer.
- Microserviços: Muitos “pedacinhos”, cada um com seu dono ou time. Integração é por rede (uma parte pede informação à outra). O desafio é coordenar times, contratos e deploys.
- Híbrido: Algumas jornadas no monolito, outras nos pedacinhos; o impacto da mudança depende de qual caminho a feature usa.
Vale perguntar: essa feature toca no monolito ou em microserviços? Quantos sistemas ou times?
Conclusão
Conhecer o cenário (monolito, microserviços, híbrido) evita decisões erradas de escopo e prazo e alinha expectativa com engenharia e negócio.