Neste episódio o Luiz Costa, CTO da Beep Saúde, compartilha a jornada de arquitetura de sistemas desde a decisão de usar microsserviços até a volta para monolitos modulares. Durante a conversa são explorados pontos como os desafios que a arquitetura baseada em microsserviços trouxe e como a migração “inversa” aconteceu.
A maior parte do custo de um software vem da mudança dele. Se o acoplamento for alto, o custo dessa mudança será muito alto, e isso vai fazer você andar devagar.
O crescimento rápido da Beep Saúde e a evolução de seus produtos levaram a equipe a enfrentar desafios técnicos. Inicialmente, a empresa utilizava um monolito baseado em Ruby on Rails para dar suporte ao seu MVP.
Com o tempo, à medida que o código crescia e se tornava cada vez mais acoplado, surgiram problemas frequentes de manutenção e escalabilidade. A solução, na época, parecia clara: dividir o monolito em microsserviços para organizar melhor as funcionalidades e reduzir os impactos de alterações no sistema.
Essa abordagem inicial foi baseada nas práticas em alta no mercado, mas logo vieram os primeiros desafios. Desde a falta de ferramentas maduras à época até problemas de infraestrutura e monitoramento, o custo operacional aumentou muito. Além disso, o foco da equipe foi desviado de problemas de negócio para questões de comunicação e integração entre serviços.
Apesar de ter criado alguns microsserviços, a equipe da Beep percebeu que a complexidade adicional não se justificava no contexto da empresa. O tempo gasto para gerenciar logs, tracing e autenticação entre serviços ultrapassava os benefícios esperados. Além disso, a baixa maturidade da infraestrutura e a escassez de recursos dedicados à operação tornaram inviável a manutenção desse modelo.
Outro ponto importante foi o impacto negativo na velocidade de entrega. Problemas como timeouts e inconsistências entre serviços distribuídos eram recorrentes, prejudicando a experiência do cliente e consumindo boa parte do tempo da equipe. Ficou claro que a arquitetura de microsserviços, naquele momento, não atendia às necessidades da empresa.
A mudança para um monolito modular não foi imediata nem drástica. A equipe decidiu adotar uma abordagem evolutiva, mantendo os microsserviços existentes enquanto reorganizava o código interno do monolito. O objetivo principal era criar módulos bem definidos e desacoplados dentro de uma única aplicação, garantindo que as dependências fossem controladas.
Inspirados em princípios como o Domain-Driven Design (DDD) e a arquitetura de portas e adaptadores (hexagonal), eles separaram o código de negócio das dependências de framework, permitindo uma maior flexibilidade para ajustes futuros. Essa abordagem também facilitou o treinamento de novos desenvolvedores e reduziu significativamente o tempo de entrega de novas funcionalidades.
Embora a transição tenha trazido diversos benefícios, desafios também surgiram. Um dos maiores foi adaptar a equipe à nova abordagem. Desenvolvedores acostumados com o padrão “Rails-Way” precisaram aprender a lidar com módulos mais isolados e indireções para acesso a frameworks e recursos externos.
Outro ponto crítico foi a consistência eventual em sistemas distribuídos. Mesmo com apenas dois sistemas principais, problemas como atrasos na propagação de eventos e inconsistências temporárias entre módulos exigiram um cuidado extra no design do sistema e na operação.
A escolha pelo monolito modular trouxe diversos ganhos para a Beep Saúde. Entre eles:
Para equipes que estão considerando migrar de microsserviços para um monolito modular, Luiz Costa compartilha algumas dicas valiosas:
O case da Beep Saúde é uma prova de que nem sempre as tendências de mercado são a melhor escolha para todos os contextos. Ao apostar no monolito modular, a empresa conseguiu equilibrar simplicidade e eficiência, voltando a focar no que mais importa: entregar valor ao cliente.
Se você deseja aprender mais sobre este tema, então assista à Masterclass sobre Monolitos Modulares conduzida pelo Jhonathan Soares aqui na Escola Forja.
