Você mantém um monolito legado e sabe as dores que sente: o deploy é coordenado na mão, um time trava o outro, e mexer em qualquer coisa é arriscado.
Aí alguém sugere a saída óbvia: quebrar tudo em microsserviços. Meses depois você não tem microsserviços, tem um monolito distribuído, com o mesmo problema de antes espalhado por quinze repositórios e uma conta de nuvem três vezes maior.
Essa aula é sobre o caminho do meio. Jhonathan Soares lidera a tribo de carrinho do Mercado Livre, onde a Black Friday bate picos de 25 a 30 milhões de requisições por minuto, e mostra como modularizar sem apostar em numa reescrita arriscada.
O que você ganha com essa aula
- Descobre por que migrar um monolito mal estruturado para microsserviços costuma piorar as coisas e custar mais caro.
- Aprende a defender uma mudança de arquitetura usando a linguagem financeira, e para de ouvir "não" do seu gestor quando pede tempo para arrumar a casa.
- Ganha um teste objetivo para saber se seus módulos estão realmente independentes.
- Entende como escalar só a parte do sistema que recebe carga, sem separar o sistema inteiro em serviços.
- Aprende a modernizar um legado aos poucos e de forma controlada.
- Enxerga por que a forma como seus times se organizam limita a arquitetura que você consegue sustentar, por mais bonito que esteja o diagrama.
- Sabe o que fazer quando você já foi longe demais e tem microsserviços demais resolvendo coisa de menos.
Se você acha que já leu sobre isso, repare no que quase nunca aparece nos artigos: quando o monolito modular não é a resposta, como fazer a travessia sem parar o roadmap por seis meses, e o que muda no banco de dados durante a migração.
Para quem é
Tech leads e líderes técnicos que precisam justificar decisões de arquitetura para quem paga a conta. Devs sêniores que herdaram um sistema difícil de mudar e não sabem por onde começar. Quem está começando um produto novo e não quer criar um problema caro no ano que vem.
Para quem não é
- Quem quer uma receita pronta de pastas para copiar no projeto.
- Quem procura garantia de que microsserviços são errados.
A aula é sobre quando cada opção faz sentido, não sobre eleger um vencedor.
A arquitetura chata é a que deixa você gastar tempo com o que o cliente paga. Assista à aula e volte para o seu sistema com um plano estruturado de evolução, não com uma reescrita total.