Monolito, microserviços ou híbrido: por que o cenário muda tudo
Você pede a mesma mudança em dois projetos. No primeiro a engenharia diz: "Sim, tranquilo." No segundo: "Isso é grande. Vai envolver vários times." O pedido foi igual. O que mudou? Quase sempre o cenário arquitetural.
Duas empresas. Empresa A: um sistema único que faz tudo — cadastro, pedido, pagamento, estoque, notificação, relatórios. É o monolito. Empresa B: cada parte é um sistema — pedidos, pagamento, estoque. Cada um roda sozinho. É microserviços. Você pede: "Alterar o fluxo de cancelamento de pedido." A frase é a mesma; o impacto pode ser completamente diferente. Monolito é como um prédio único onde todos os departamentos trabalham no mesmo lugar. Vantagens: comunicação mais simples, deploy único. Desvantagens: pode ficar gigante, legado se acumula. Microserviços: vários "prédios", cada um com sua equipe; se comunicam por rede. Vantagens: escalar por serviço, times autônomos. Desvantagens: integrações complexas, latência, mais coordenação. Sua funcionalidade pode atravessar vários "prédios".
Antes de falar de prazo: isso roda em qual sistema? Quantos sistemas participam? Tem mais de um time? "Ao cancelar o pedido, reembolsar automaticamente e notificar por e-mail." No monolito o módulo de pedidos chama o de pagamento e o de notificação — tudo no mesmo código. Nos microserviços: serviço de pedidos recebe o cancelamento, serviço de pagamento é acionado (e chama gateway externo), serviço de notificação escuta evento, estoque atualiza. Várias APIs, eventos assíncronos, times diferentes, deploys diferentes. A frase é a mesma; o impacto é outro.
Poucas empresas são 100% monolito ou 100% microserviços. A maioria é híbrida: parte em sistema antigo, parte já separada. Algumas mudanças são simples, outras atravessam os dois mundos. Se você não sabe qual parte está sendo impactada, está prometendo no escuro. Prazo não é só esforço técnico. É dependência entre times, deploy sincronizado, testes integrados. Em microserviços a coordenação vira fator crítico. Antes de fechar requisito que envolva várias áreas: isso atravessa mais de um serviço? Quem é responsável por cada parte? Tem contrato de API? Essa mudança exige coordenação de deploy? Uma funcionalidade pode parecer simples pro usuário e ser complexa na arquitetura. Adicionar um campo opcional na tela pode ser fácil — mas se esse campo tem que ir pra outro banco, ser enviado pro parceiro e entrar em evento assíncrono, a complexidade explode. Em microserviços os sistemas se falam por rede. Rede significa latência, timeout, falha. Nada disso aparece na tela, mas impacta esforço.
Monolito não é melhor; microserviços não são melhores. São contextos diferentes — e contexto muda complexidade. A mesma frase pode ser uma semana num cenário e dois meses em outro.
No próximo post: dono do dado. Porque quando ninguém sabe quem é a fonte da verdade, o caos começa em silêncio.
