Monólito modular vs microsserviços em PHP: como decidir

A decisão entre monólito modular vs microsserviços em PHP não é resolvida pelo número de módulos, pela antiguidade do código nem pela popularidade de uma arquitetura. Uma aplicação empresarial pode crescer de forma saudável em um único deploy se mantiver limites claros. Por outro lado, dividi-la prematuramente pode transformar chamadas internas simples em uma rede de contratos, filas, tentativas e problemas de coordenação.

A pergunta útil não é «devemos usar microsserviços?», mas «qual capacidade de negócio precisa evoluir, falhar, ser implantada ou escalar de forma independente, e podemos assumir o custo de operá-la assim?». A resposta deve partir do domínio e da operação real, não de um diagrama-alvo.

O crescimento funcional não exige serviços separados

Adicionar integrações, processos assíncronos ou áreas de produto não implica que cada um deva ter seu próprio serviço. Um monólito pode conter módulos bem delimitados, jobs em segundo plano, filas e adaptadores para sistemas externos sem perder coerência operacional.

A primeira intervenção costuma ser reduzir o acoplamento interno. Se um módulo de faturamento importa diretamente classes de pedidos, modifica suas tabelas ou conhece regras internas de estoque, o problema não é corrigido automaticamente ao mover o código para outro repositório. Ele apenas se transforma em acoplamento de rede e de dados.

Um monólito modular busca fazer com que cada capacidade tenha uma interface interna explícita, dependências direcionadas e regras próprias. Em PHP, isso pode se materializar em namespaces por domínio, contratos de aplicação, controladores enxutos, casos de uso definidos e adaptadores para persistência ou APIs externas. O fato de implantar tudo junto continua sendo compatível com essas fronteiras.

O que analisar antes de mudar a arquitetura

Antes de discutir tecnologia, identifique as capacidades de negócio: por exemplo, gestão de pedidos, catálogo, identidade, faturamento, processamento de documentos ou notificações. Uma capacidade não equivale necessariamente a uma entidade nem a uma tela; ela agrupa regras e decisões que deveriam mudar por motivos semelhantes.

• Responsável: determine quem mantém as regras, prioriza mudanças e responde por incidentes.
• Dados: identifique quais informações cada capacidade cria e governa, quem pode modificá-las e quais leituras cruzadas ela precisa.
• Fluxos críticos: desenhe o percurso de uma operação relevante, incluindo validações, dependências externas e etapas assíncronas.
• Ritmo de mudança: diferencie modificações frequentes de mudanças pontuais. A frequência isolada não basta; importa se ela obriga a coordenar equipes ou releases.
• Perfil de carga: separe o tráfego interativo de tarefas intensivas de CPU, memória, armazenamento ou chamadas a terceiros.
• Impacto de falha: estabeleça o que acontece se uma capacidade se degradar durante minutos ou horas e se o núcleo do negócio puder continuar operando.

Esse inventário revela dependências que frequentemente permanecem ocultas: transações compartilhadas, consultas diretas a tabelas de outros domínios, regras duplicadas em controladores e tarefas agendadas que atualizam vários domínios. Extrair sem resolvê-las produz serviços formalmente separados, mas funcionalmente interligados.

Seis sinais para manter um monólito modular

Estes sinais favorecem reforçar o design interno em vez de distribuir responsabilidades:

1. As mudanças costumam atravessar vários módulos. Se uma funcionalidade de negócio exige modificar pedidos, preços e faturamento de forma coordenada, separar pode multiplicar os deploys e os contratos.
2. A consistência imediata é central. Quando uma operação precisa de uma única transação de banco de dados para preservar invariantes críticos, um limite distribuído adiciona decisões complexas de compensação.
3. A equipe é pequena ou compartilha a responsabilidade. Vários serviços exigem disciplina de operação, plantões, pipelines, versões e diagnóstico para cada unidade.
4. A carga escala de forma semelhante. Se os componentes crescem no mesmo ritmo e não há um gargalo isolável, a separação não traz uma vantagem clara.
5. Os limites de domínio ainda são instáveis. Extrair uma capacidade enquanto suas regras, vocabulário e responsabilidades mudam constantemente fixa uma fronteira prematura.
6. A observabilidade e a automação são limitadas. Sem logs estruturados, métricas, traces, alertas e deploys repetíveis, cada salto de rede tornará mais caro investigar um incidente.

Manter o monólito não significa aceitar código global. O objetivo é que o módulo possa evoluir com autonomia lógica, mesmo que compartilhe processo, repositório e release com outros.

Seis sinais que justificam um serviço independente

A extração é mais defensável quando várias destas condições se combinam, não quando apenas uma aparece:

1. Existe uma responsabilidade delimitada e compreensível. O serviço tem uma missão concreta, regras coesas e uma linguagem de domínio própria.
2. Ele pode ser responsável por seus dados. Gerencia seu armazenamento e expõe operações, eventos ou consultas acordadas, em vez de permitir acesso direto às suas tabelas.
3. Ele realmente precisa de deploys independentes. Seu ciclo de mudança deve avançar sem coordenar cada release com o núcleo.
4. Sua carga é diferenciada. Um processo de conversão, busca, geração de arquivos ou cálculo intensivo pode exigir escalabilidade e recursos diferentes.
5. Sua falha pode ser isolada. O sistema pode se degradar de forma explícita se essa capacidade não responder, por meio de tentativas, estados pendentes ou trabalho adiado.
6. Há responsabilidade operacional suficiente. Uma equipe ou responsável pode manter seu ciclo de vida, alertas, incidentes, segurança e compatibilidade.

Uma API, por si só, não transforma um módulo em microsserviço. A independência também depende de dados, deploy, operação e capacidade de tomar decisões sem depender dos internals de outra aplicação.

Custos que surgem ao separar responsabilidades

Uma chamada de função falha de forma diferente de uma chamada HTTP, uma mensagem em fila ou uma consulta remota. Após a extração, surgem latência, timeouts, autenticação entre serviços, limites de taxa, indisponibilidade parcial e versões incompatíveis.

O modelo de consistência também muda. Se um serviço confirma uma operação e outro não recebe ou não processa o evento, é preciso decidir como detectar o estado, tentar novamente sem duplicar efeitos e compensar quando necessário. Os consumidores de eventos devem ser idempotentes; por exemplo, processar uma mensagem duas vezes não deve emitir dois documentos nem cobrar duas vezes.

A operação ganha complexidade: correlação de requisições, traces distribuídos, painéis de métricas, retenção de logs, gestão de segredos, políticas de backup e testes de recuperação. Além disso, cada contrato precisa de regras de compatibilidade. Adicionar campos opcionais costuma ser menos disruptivo do que mudar a semântica, remover campos ou reutilizar um estado com um novo significado.

Arquitetura de transição dentro do PHP

O caminho de menor risco é modularizar antes de extrair. Defina uma camada de aplicação para cada capacidade, com casos de uso que recebam comandos ou consultas e retornem resultados bem definidos. Oculte o acesso ao banco de dados atrás de repositórios ou portas quando isso representar uma dependência relevante; não transforme cada classe em uma abstração sem propósito.

O restante do monólito deve utilizar o módulo por meio de sua interface pública interna, e não por suas entidades ou tabelas. Se forem necessárias notificações assíncronas, publique eventos de domínio ou de integração a partir de um ponto controlado. Um padrão de saída transacional pode ajudar a registrar a mudança de negócio e o evento pendente na mesma transação, para que um processo posterior o entregue de forma confiável.

Essa fase permite verificar se o limite é real. Se a interface interna cresce sem parar, exige objetos privados de outros módulos ou precisa de transações compartilhadas em cada caso de uso, ainda não é uma candidata sólida à separação.

Como definir o primeiro limite de serviço

O primeiro serviço deve ter uma responsabilidade fácil de explicar e uma dependência limitada do núcleo. Documente quatro elementos antes de escrever infraestrutura:

• Responsabilidade: quais decisões toma e quais ficam explicitamente fora.
• API ou eventos: entradas, saídas, erros, autenticação, limites de tempo e idempotência.
• Responsabilidade pelos dados: o que armazena, quais identificadores externos preserva e quais informações consulta por meio de contratos.
• Compatibilidade: como produtores e consumidores coexistirão durante mudanças de versão, incluindo mensagens atrasadas.

Evite projetar uma API como espelho das tabelas. Um contrato deve expressar operações ou fatos de negócio, não expor detalhes de persistência que bloquearão mudanças posteriores.

Exemplo: processamento de documentos sem fragmentar o backoffice

Considere um backoffice PHP que gerencia processos e precisa gerar, validar e armazenar documentos. No início, o processamento pode existir como um módulo interno: recebe uma solicitação de geração, registra o trabalho, executa uma tarefa assíncrona e atualiza um estado visível para o usuário.

A extração se torna razoável se a geração consome recursos muito diferentes, precisa de dependências específicas de conversão, recebe picos próprios e pode funcionar com uma solicitação documental que contenha os dados mínimos necessários. O serviço documental não deveria consultar livremente as tabelas do processo. O backoffice pode enviar uma ordem com um identificador, template aplicável, versão dos dados e destino; o resultado retorna como evento ou estado consultável.

Antes disso, convém esclarecer que um template define a estrutura de saída, enquanto um modelo pode se referir a dados de domínio ou a um sistema de IA. Se fosse incorporada IA para classificar documentos, seriam necessários um caso de uso delimitado, avaliação com dados representativos, revisão humana diante de decisões sensíveis, proteção de dados, controle de custo e uma alternativa manual ou baseada em regras quando o fornecedor falhar.

Verificações antes de extrair

Não trate a extração como um deploy técnico isolado. Defina uma ativação gradual para um subconjunto controlado de operações, diferente de anunciar a mudança a todos os usuários. Mantenha um plano de convivência e reversão enquanto o comportamento é validado.

• Testes de contrato entre produtor e consumidor, além de testes unitários e de integração.
• Métricas de latência, erros, tentativas, filas pendentes, duplicados e tempo até a conclusão do processo.
• Identificadores de correlação para acompanhar uma operação entre o monólito, as filas e o serviço.
• Procedimentos de recuperação: reexecução segura, reconciliação de estados, backup e restauração.
• Regras explícitas para degradação funcional quando o serviço não estiver disponível.
• Um critério de saída: quais evidências demonstrarão que a extração reduziu um problema concreto e não apenas deslocou a complexidade.

A melhor decisão arquitetural é aquela que protege a evolução do produto sem impor uma plataforma desproporcional. Um monólito PHP modular, mensurável e bem delimitado costuma ser o passo correto até que uma capacidade demonstre uma necessidade verificável de independência.