"Monólito não escala" é uma afirmação que ouço com frequência e concordo cada vez menos. A maioria dos sistemas que já vi migrar para microsserviços prematuramente trocou um problema de performance resolvível por um problema de complexidade operacional permanente.
O que realmente limita um monólito
Não é o monólito em si — é banco de dados sem índice certo, ausência de cache, consultas N+1 não resolvidas, tudo rodando de forma síncrona quando deveria ser assíncrono. Resolvido isso, um monólito Laravel bem escrito aguenta uma quantidade de tráfego muito maior do que a maioria assume, e o Simulado Solidário é prova disso em produção.
Quando aí sim vale separar
Separar em serviços começa a valer quando times diferentes precisam deployar de forma independente, ou quando uma parte específica do sistema tem um perfil de carga completamente diferente do resto — por exemplo, processamento pesado de relatório que não deveria competir por recurso com a aplicação principal. Nesses casos, a decisão não é sobre performance pura, é sobre isolamento operacional.
A régua de sempre
Essa decisão segue o mesmo critério que aplico em qualquer escolha de arquitetura: resolve o problema que eu realmente tenho, ou é complexidade adicionada por moda? O mesmo raciocínio que uso para decidir construir do zero ou usar pronto vale aqui — só que aplicado à decisão de dividir ou não um sistema em partes menores.
