Separar o que é transação, o que é batch e o que é integração pode ser a diferença entre caos e controle. ERP modular precisa de infraestrutura modular.

O Sintoma: travou tudo de novo. E ninguém sabe por quê.

Era uma sexta-feira comum em uma indústria de médio porte. O time de vendas finalizava pedidos, a expedição já organizava as rotas do dia seguinte e o financeiro rodava o contas a pagar no Protheus. Tudo fluía — até que parou. Literalmente.

O ERP travou. As transações começaram a demorar minutos. A equipe de TI recebeu uma enxurrada de ligações. Ninguém conseguia trabalhar. E como acontece na maioria das empresas que cresceram rápido, a infraestrutura não acompanhou.

O servidor era o mesmo há 4 anos. Tudo rodava junto: aplicação, banco, batch, integração. Um monólito disfarçado de ambiente corporativo.

Esse tipo de cenário é mais comum do que parece. E a raiz do problema está menos na performance do Protheus e mais em uma falha arquitetural invisível: a ausência de uma arquitetura em camadas.

O Diagnóstico: o ERP pode até ser modular, mas sua infraestrutura precisa ser também.

Quando uma empresa adota uma solução como o Protheus, ela costuma seguir um caminho natural: começar pequeno, com poucos módulos, e crescer conforme a necessidade. O problema é que, com o tempo, os serviços se multiplicam, o volume de dados cresce e os processos se tornam mais complexos — mas tudo continua rodando num ambiente único, centralizado, frágil.

Essa abordagem é insustentável.

A arquitetura em camadas propõe uma separação funcional entre os diferentes tipos de cargas e responsabilidades do ambiente. Ela parte do princípio que:

• Transações (OLTP) precisam de baixa latência e alta disponibilidade.
• Jobs batch demandam alta capacidade de processamento, mas são tolerantes a variações.
• Integrações exigem isolamento para evitar interferência nas operações principais.

A Solução: distribuir para escalar.

A arquitetura em camadas para ambientes TOTVS pode ser implementada de forma gradual, respeitando o momento de cada empresa. Ela costuma seguir três níveis básicos:

1. Camada de Aplicação

É onde rodam os serviços do Protheus (SmartClient, AppServer). Aqui o foco é garantir resposta rápida ao usuário. O ideal é que essa camada esteja isolada de jobs pesados e rotinas automáticas.

• Load balancing pode ser usado para escalar horizontalmente.
• Monitoramento contínuo garante SLA das transações.

2. Camada de Integração

APIs, Webservices e conectores com marketplaces, bancos e CRMs devem ser tratados como uma camada à parte. O acoplamento dessas integrações à camada de aplicação principal é o erro mais comum.

• Separar o AppServer que cuida das integrações evita travamentos por lentidão externa.
• Orquestradores como Apache Camel ou ferramentas como TOTVS Integration Broker ajudam a centralizar e controlar.

3. Camada de Processamento

Aqui rodam os processos em lote: fechamento contábil, faturamento em massa, atualizações de estoque, etc.

• Idealmente executados em horários de menor uso.
• Rodar em servidores separados garante que, mesmo em caso de erro, o sistema transacional continue operacional.

Benefícios práticos de uma arquitetura em camadas

• Resiliência: falhas localizadas não derrubam todo o ambiente
• Performance: menos concorrência entre tarefas pesadas e interativas.
• Escalabilidade: novos serviços podem ser adicionados em nós específicos.
• Visibilidade: métricas separadas por camada facilitam o diagnóstico.
• Governança: isolar funções permite aplicar políticas de segurança mais eficazes.

Conclusão: arquitetura não é luxo, é sobrevivência.

A maioria dos problemas de performance e instabilidade que as empresas enfrentam com TOTVS não está no código, e sim na forma como o ambiente foi estruturado.

Adotar uma arquitetura em camadas não é uma reformulação completa. É uma readequação inteligente que respeita o que a empresa já tem e prepara o ambiente para o que está por vir. Porque crescer sem planejar a infraestrutura é como construir um prédio em cima de uma casa: vai cair. É só questão de tempo.