Como uma arquitetura baseada em microsserviços, processamento assíncrono e serviços gerenciados transformou a infraestrutura do cliente e preparou a plataforma para crescer com mais performance, segurança e eficiência operacional.
O desafio de crescer com uma infraestrutura limitada
O cliente é uma plataforma SaaS de atendimento automatizado via WhatsApp que utiliza Inteligência Artificial para responder clientes e leads em linguagem natural, 24 horas por dia.
Cada cliente pode configurar fluxos conversacionais, prompts e integrações com CRM, agendas, Google Calendar, Google Sheets e outras ferramentas, utilizando modelos como GPT-4o e Claude.
Com o crescimento da plataforma, o processamento simultâneo de mensagens passou a exigir uma infraestrutura mais robusta. Antes do projeto com a NextPage, toda a operação dependia de um único servidor dedicado, com capacidade fixa, deploys manuais e sem redundância, escalabilidade automática ou observabilidade.
O objetivo foi modernizar essa infraestrutura na AWS, criando uma arquitetura mais escalável, resiliente e preparada para a evolução do cliente.
Quando um servidor único se torna um risco para a operação?
A concentração de todos os recursos em uma única máquina também limitava a capacidade de resposta da plataforma. Com um processamento estimado em aproximadamente 100 mensagens por minuto, períodos de maior movimento podiam gerar sobrecarga, atrasos e falhas no processamento. A plataforma responsável por organizar as mensagens, apresentava instabilidades que podiam levar à perda de informações e interrupção de conversas.
As atualizações do sistema também exigiam intervenção manual, com processos que podiam levar de 30 a 60 minutos e apresentar risco de indisponibilidade. Caso fosse necessário retornar a uma versão anterior, não havia um processo rápido para realizar essa mudança.
Na área de segurança, mais de 15 credenciais, como chaves de acesso e tokens, ficavam armazenadas em arquivos no servidor. Além de não haver renovação periódica dessas informações, o acesso não era centralizado nem acompanhado de forma adequada.
A equipe também tinha pouca visibilidade sobre o funcionamento dos serviços. Sem acompanhamento centralizado de registros, indicadores e alertas, problemas podiam permanecer sem identificação por horas. Esse conjunto de limitações aumentava o esforço operacional e dificultava uma resposta rápida diante de falhas ou picos de demanda.
A arquitetura desenhada pela NextPage
A NextPage redesenhou a infraestrutura do cliente na AWS, substituindo a concentração de recursos por uma arquitetura distribuída em serviços independentes. A solução utiliza Amazon ECS com Fargate e processadores Graviton, que permitem executar os serviços sem a necessidade de administrar diretamente os servidores que sustentam a aplicação.
A arquitetura foi inicialmente dividida em três serviços, cada um com uma função específica. O Gateway recebe e autentica as mensagens. O Publisher organiza esse conteúdo e o encaminha para processamento. Já o Consumer concentra as tarefas de maior demanda, como IA, RAG, integrações, ferramentas, CRM e envio das respostas.
Essa divisão permite que os recursos sejam ajustados de acordo com a necessidade de cada serviço. O Consumer, por exemplo, pode aumentar de uma para até três unidades durante períodos de maior demanda, chegando a 24 vCPUs disponíveis para processamento.
O ambiente também evoluiu durante o projeto. O escopo inicial previa três clusters, mas a estrutura chegou a quatro clusters ECS e 11 serviços ativos, incorporando novos recursos para disparos, follow-ups, CRM e homologação.
Microsserviços e processamento assíncrono
A substituição da antiga plataforma (responsável por organizar as mensagens) pelo Amazon SQS foi uma das principais mudanças do projeto. O SQS funciona como uma fila intermediária, na qual as mensagens recebidas ficam armazenadas até que um serviço esteja disponível para processá-las. Dessa forma, uma alta concentração de solicitações não precisa ser processada simultaneamente.
O fluxo passou a seguir esta sequência:
• Mensagem recebida → Gateway → Publisher → SQS → Consumer → processamento de IA → resposta
Esse modelo permite absorver variações de demanda com maior estabilidade. A estrutura também conta com uma Dead-Letter Queue (DLQ), que recebe mensagens que não puderam ser processadas após três tentativas. Elas permanecem armazenadas por até 14 dias, permitindo análise e novo processamento.
Com a nova arquitetura, a capacidade estimada passou de aproximadamente 100 para mais de 1.000 mensagens por minuto, um aumento de até 10x no throughput. A estrutura também pode ampliar os recursos de processamento automaticamente, com escalabilidade estimada em aproximadamente dois minutos.
Segurança e automação operacional
A modernização também reorganizou o gerenciamento das credenciais utilizadas pela plataforma. As informações que antes ficavam armazenadas em arquivos no servidor passaram para o AWS Secrets Manager, serviço que centraliza o armazenamento e o controle dessas informações.
O acesso foi distribuído de acordo com a função de cada serviço. Assim, cada componente recebe somente as permissões necessárias para executar suas tarefas, reduzindo a exposição de credenciais e recursos.
A infraestrutura também foi preparada para integração com GitHub Actions por meio de OIDC, permitindo automatizar processos sem depender de chaves de acesso permanentes.
Na camada externa, Amazon CloudFront e AWS WAF passaram a proteger e controlar o acesso à aplicação. O WAF permite estabelecer limites de requisições e bloquear padrões associados a ataques, como SQL Injection.
A rede foi estruturada com Amazon VPC, subnets privadas e Security Groups, criando diferentes níveis de acesso entre os componentes. O AWS KMS complementa essa estrutura com recursos de criptografia.
Outro avanço foi a adoção do Terraform, que permite definir a infraestrutura em arquivos versionados. Com isso, as configurações podem ser reproduzidas, revisadas e alteradas de maneira controlada.
O projeto foi organizado em três etapas: rede, recursos de processamento e camada de acesso. A implementação também passou por testes automatizados, com 14 arquivos desenvolvidos em Terratest e Go para verificar o funcionamento da infraestrutura.
O papel da NextPage no projeto
A NextPage foi responsável pelo desenho e pela implementação da infraestrutura AWS, desde a definição da arquitetura até o provisionamento dos recursos e a preparação do ambiente para operação.
O trabalho incluiu arquitetura, Terraform, segurança, gerenciamento de credenciais, monitoramento, proteção da aplicação, configuração dos serviços e preparação do ambiente para integração contínua.
A documentação técnica de arquitetura ultrapassou 870 linhas, complementada por mais de 16 documentos com requisitos, critérios de aceite, testes, troubleshooting e orientações de operação.
Mesmo a adaptação do código da aplicação ficando sob responsabilidade do cliente, a NextPage produziu um documento com as alterações necessárias, orientou a implementação e posteriormente revisou os Pull Requests do cliente.
Essa divisão preservou a lógica de negócio da plataforma. O código responsável pelo NeuralChat, incluindo IA, RAG, ferramentas, CRM e integrações, permaneceu sob responsabilidade do cliente e não foi reescrito pela NextPage.
Assim, a atuação da NextPage ficou concentrada naquilo que era essencial para a transformação do ambiente: arquitetura, infraestrutura, segurança, automação e orientação técnica para a adaptação da aplicação.
Resultados alcançados
A modernização trouxe ganhos mensuráveis em diferentes aspectos da operação:
|
MÉTRICA |
ANTES |
DEPOIS |
|
Disponibilidade |
~95% | 99,9%+ |
|
Recuperação |
30 a 60 min |
< 2 min |
|
Resposta em picos |
> 5 s |
< 2 s |
|
Processamento |
~100 msg/min | > 1.000 msg/min |
|
Deploy |
30 a 60 min |
5 a 10 min |
| Detecção de problemas | Horas |
Minutos |
| Custo por mensagem | ~US$ 0,005 |
~US$ 0,001 |
Os números representam:
- 99% de redução estimada no downtime;
- 3x menos tempo de resposta em períodos de pico;
- 10x mais capacidade de processamento;
- 80% de redução no tempo de deploy.
A identificação de problemas também passou de horas para minutos, representando uma redução estimada de 95% no MTTD, indicador que mede o tempo necessário para detectar um incidente.
Na infraestrutura, o custo mensal estimado passou de US$ 300 a US$ 500 para uma projeção de US$ 230 a US$ 350 no modelo On-Demand. A arquitetura também permite adequar os recursos à demanda, reduzindo a capacidade mantida durante períodos de menor utilização.
Uma nova base para evolução
A modernização transformou a infraestrutura do cliente sem alterar sua lógica de negócio. O produto continuou sob responsabilidade da equipe do cliente enquanto a NextPage estruturou uma base AWS capaz de acompanhar suas necessidades de crescimento.
A nova arquitetura combina serviços independentes, processamento por filas, escalabilidade automática, gerenciamento centralizado de credenciais, monitoramento e proteção da aplicação. O resultado é uma operação com maior capacidade de processamento, recuperação mais rápida e mais controle sobre a infraestrutura.
O case também demonstra a atuação da NextPage em projetos de cloud que exigem decisões técnicas alinhadas às necessidades do negócio, desde o desenho da arquitetura até a implementação e validação do ambiente.
Sobre a NextPage
A NextPage atua na modernização de aplicações e infraestruturas cloud, apoiando empresas na construção de ambientes mais escaláveis, seguros e eficientes.
Entre nossas principais frentes estão:
- Modernização de aplicações e infraestrutura;
- Migração e otimização de ambientes AWS;
- Arquiteturas escaláveis e resilientes;
- Segurança e observabilidade;
- Automação de operações;
- Apoio técnico para evolução de ambientes cloud.
No projeto deste case, a NextPage combinou arquitetura, engenharia e serviços AWS para criar uma infraestrutura capaz de sustentar a evolução de uma plataforma SaaS de Inteligência Artificial.
➡️ Fale com nossos especialistas aqui: https://nxtpg.io/especializada.
