Uma coisa tem me incomodado nos últimos anos: tratar microsserviços e SPAs como padrão antes de entender o problema. Parece que aplicação web já vem com a arquitetura escolhida: uma API no backend e uma SPA no frontend. Ainda nem entendemos o que precisamos resolver e já temos duas aplicações para cuidar.

Para uma startup enxuta, eu começaria questionando essa escolha. O que o produto ganha com ela? Esse ganho compensa manter contratos, sincronizar estado e coordenar autenticação, testes e deploys entre os dois lados?

Quem desenvolve paga essa conta em complexidade. O cliente pode pagar em prazo maior para receber uma funcionalidade. Se existe uma necessidade concreta, ótimo. Mas “é assim que se faz hoje” é uma justificativa ruim para assumir esse custo.

Sim, a IA escreve os dois lados mais rápido. Você ainda precisa entender o conjunto, revisar o código e responder pelo que colocou em produção. Sem curadoria humana, dá para produzir um projeto difícil de manter em tempo recorde. A velocidade para escrever código não elimina o trabalho de sustentar o sistema.

Minha preferência é monólito primeiro, com código limpo, bem testado e responsabilidades claras. A separação precisa justificar o que custa.

Uma distinção antes de continuar: separar frontend e backend e dividir o backend em serviços são decisões diferentes. Uma SPA pode consumir um backend monolítico. Nas duas discussões, porém, faço a mesma pergunta: qual problema essa separação resolve?

No Atenda, tivemos uma razão concreta para manter dois serviços. É sobre essa escolha que quero falar.

O atendimento já existia

Já tínhamos um motor de atendimento. Depois, acrescentamos uma aplicação para o cliente criar sua conta, contratar o serviço e começar a usar. Essa foi a origem da divisão: gestão de um lado, execução do atendimento do outro.

Não extraímos dois serviços de um monólito existente. O produto cresceu em torno de um motor que já funcionava, e manter essa fronteira fez sentido.

Quem administra precisa configurar o uso do produto. Quem conversa com a secretária precisa ser atendido. Enquanto melhoramos uma tela de onboarding, as conversas continuam acontecendo.

Uma mudança nessa tela não deveria exigir parar a secretária. Manter essas responsabilidades em serviços separados nos deu liberdade para fazer deploys na gestão sem interromper a execução do atendimento.

Esse é o ganho que importa. Somos duas pessoas cuidando do produto; coordenar uma intervenção no atendimento a cada melhoria na gestão seria trabalho a mais e motivo para adiar entregas.

A fronteira vem antes do serviço

Um monólito modular também tem fronteiras. Cada módulo concentra suas regras e oferece uma interface para os outros. Você pode separar responsabilidades dentro da mesma aplicação, sem colocar uma rede entre elas.

Por outro lado, é possível ter vários serviços em que qualquer alteração exige mexer em todos. Você distribuiu o código e ganhou o trabalho de operar vários processos, mas continua precisando coordenar tudo.

Por isso, começo por duas perguntas:

1. Qual decisão pertence a cada parte?
2. O que justifica executá-las separadamente?

No Atenda, onboarding e gestão cuidam de como o cliente começa e administra o uso. A automação cuida de executar o atendimento. A necessidade de continuar atendendo enquanto a gestão evolui justificou a separação operacional.

Essa divisão tem relação com contextos delimitados, do design orientado ao domínio: deixar claro onde cada conjunto de conceitos e regras vale. Dois serviços, sozinhos, não garantem isso. Se um precisa conhecer os detalhes internos do outro, ainda há trabalho a fazer na fronteira.

O contrato precisa permitir mudanças

Os dois serviços se comunicam por contrato. Cada lado precisa saber o que pode pedir, quais informações recebe e o que elas significam. Não precisa conhecer a implementação do outro.

Isso permite mudar a implementação de um lado preservando o acordo com o outro. Se uma alteração interna exige atualizar os dois serviços juntos, vale investigar o que vazou pela fronteira.

O contrato também inclui o comportamento diante de falhas. O que acontece se uma chamada demora? Se falha? Se chega duas vezes? Como mudar uma informação sem quebrar a versão que ainda está em produção?

É aqui que entram timeouts, retentativas, idempotência e compatibilidade. Alguém precisa decidir e verificar como tudo isso funciona. A IA pode ajudar na implementação; a responsabilidade pelo merge continua sendo nossa.

Deploy independente tem limites

Separar os processos não garante que o atendimento sobreviva a qualquer falha na gestão. Se o atendimento depender de uma consulta a ela para continuar, essa dependência continua existindo durante um deploy ou uma indisponibilidade.

O mesmo vale para mudanças no contrato. Reorganizar uma tela e alterar uma informação consumida pelo atendimento têm consequências diferentes. A segunda exige cuidar da compatibilidade entre os dois lados.

O benefício está em reduzir o conjunto de mudanças que precisam acontecer juntas. Para avaliar uma divisão dessas, eu perguntaria:

• As responsabilidades estão claras ou os dois lados tomam as mesmas decisões?
• Uma mudança comum pode ser entregue em apenas um deles?
• Existe uma necessidade operacional que justifique a separação?
• A equipe consegue manter a comunicação e lidar com suas falhas?

Se separar só acrescenta trabalho, eu manteria junto.

Monólito primeiro

Nem microsserviços por padrão, nem um monólito espaguete. Seu cliente não liga para como você organiza os serviços. Ele liga para o resultado. Pessoas te pagam por uma solução, não por um software.

Para uma startup enxuta, continuo defendendo monólito primeiro: código limpo, bem testado e fronteiras claras. Com o crescimento do sistema, esse monólito pode virar uma federação de serviços, cada um com sua responsabilidade e seus contratos. Pode, não precisa.

No Atenda, tivemos uma razão concreta para separar: evoluir a gestão sem parar o atendimento da secretária. É esse tipo de retorno que eu espero de uma decisão de arquitetura.