O movimento de migração para Microsserviços nos últimos anos foi guiado pela promessa de escalabilidade e independência dos times. Contudo, em vários times, o que vemos é que essa transição, muitas vezes, gerou uma complexidade silenciosa. A dor não está mais na lentidão de um deploy monolítico, mas no custo de observabilidade, na latência da rede e na dificuldade de garantir transações distribuídas. Esta edição foca em como resgatar a pragmática, discutindo onde o Monolito Modular ainda vence e quais padrões de resiliência são obrigatórios para não sucumbir ao caos da arquitetura distribuída.

📬 Sobre o Bora Radar

Um formato conciso e curado para informar profissionais de tecnologia sobre as transformações nas stacks modernas; sem hype nem ruído e com o contexto que importa, usamos automação, IA e a curadoria do Gil para condensar os principais movimentos da semana em uma leitura de menos de 10 minutos.

🏰 Monolito vs. Monolito Modular: Onde a Simplicidade Vence

A ideia de que todo crescimento de software exige microsserviços é um mito. Um dos fatores que levam ao fracasso de arquiteturas distribuídas é a transição precoce, antes que o time esteja pronto cultural e tecnicamente. O Monolito Modular é a abordagem de criar um sistema único, mas rigorosamente separado em módulos internos por domínio (BFF, Auth, Pagamento, etc.), que se comunicam através de interfaces e não de chamadas de rede.

Destaques:

* Separação por Módulos: Estruturar o código interno com limites rígidos (por exemplo, usando pacotes ou namespaces bem definidos) para que as equipes possam trabalhar em seus domínios com independência.

* Refatoração Controlada: O Monolito Modular permite refatorar e isolar bounded contexts sem o custo imediato de uma rede e infraestrutura de deploy distribuída.

* Transição Lenta: Ele serve como o ponto de partida ideal para futuras extrações. Quando um módulo se tornar um gargalo de performance ou precisar ser escalado de forma independente, ele pode ser extraído para um microsserviço.

📉 O Custo Oculto da Distribuição: Observabilidade e Latência

O custo de migrar para microsserviços vai além do aumento de instâncias de VM/Contêiner; ele se manifesta em custos de engenharia. Em arquiteturas distribuídas, a latência de rede é inevitável. Mais crítico ainda é o custo de observabilidade: quando uma transação falha, é preciso rastrear a requisição através de dezenas de serviços.

Destaques:

* Distributed Tracing é Obrigatório: Implementar o tracing de requisições fim-a-fim (usando padrões como OpenTelemetry) é a única forma de depurar falhas e gargalos de latência.

* Monitoramento de Latência: Uma chamada local (in-process) é sub-milissegundo; uma chamada de rede (inter-service) pode adicionar de 10ms a 100ms. O impacto na experiência do usuário final deve ser medido ativamente.

* Complexidade do Rollback: Em um monolito, o rollback é simples; em microsserviços, coordenar o rollback de vários serviços que podem ter processado dados e interações em diferentes estágios é complexo, exigindo estratégias como Saga Patterns.

🛡️ Padrões de Resiliência: Evitando Falhas em Cascata

A falha é garantida em um ambiente distribuído. O que determina a resiliência do seu sistema é como ele reage a essa falha. A arquitetura deve prever que serviços dependentes estarão lentos ou offline. Sem esses padrões, a falha em um microsserviço de baixa prioridade pode derrubar o sistema inteiro.

Destaques:

* Circuit Breaker: É um padrão que “abre o circuito” (para de tentar se conectar) a um serviço que está falhando repetidamente, permitindo que ele se recupere e prevenindo o desperdício de recursos.

* Retries com Backoff: Ao tentar se comunicar com um serviço falho, a aplicação deve usar tentativas (retries) limitadas e um tempo de espera exponencialmente maior (backoff) entre as tentativas para não sobrecarregar o serviço que já está em crise.

* Bulkhead (Antepara): Isolar os recursos de cada serviço. Por exemplo, dedicar um pool de threads ou conexões separadas para cada serviço dependente, garantindo que a lentidão em um não consuma todos os recursos do host principal.

🧑‍💻 A Lei de Conway e a Organização do Time

A arquitetura de software e a estrutura organizacional da empresa andam de mãos dadas, segundo a Lei de Conway. O princípio da lei é: “Organizações que projetam sistemas... são compelidas a produzir projetos cujas estruturas são cópias das estruturas de comunicação dessas organizações.” Para microsserviços funcionarem, os times também devem ser independentes.

Destaques:

* Times Orientados a Domínio: Estruturar os times em torno de um bounded context (e.g., Time de Pagamento, Time de Logística) em vez de uma função técnica (e.g., Time de Front-end, Time de Backend).

* Autonomia na Stack: Dar a cada time a autonomia para escolher a stack tecnológica mais adequada para o seu microsserviço, garantindo a especialização e a propriedade de ponta a ponta.

* Cultura de Serviço: Promover uma cultura onde cada time trata os outros times como “clientes”, definindo SLAs (Service Level Agreements) claros para a API do seu microsserviço.

📬 Gostou desta curadoria? Compartilhe com colegas e profissionais que acompanham IA, software e tendências tecnológicas.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit gpupo.substack.com