Troca com Bônus Equatorial: arquitetura serverless para uma campanha de dados pessoais em escala

O problema

O Troca com Bônus é um programa da Equatorial Goiás dentro do Programa de Eficiência Energética (PEE) da ANEEL, realizado em parceria com uma rede varejista. A plataforma que sustenta essa adesão faz três coisas: recebe o pré-registro do consumidor, avalia a elegibilidade de cada unidade consumidora segundo os critérios do programa, e dá à gestão da campanha um dashboard para acompanhar cadastros e vendas em tempo real.

Dois fatores tornavam esse projeto diferente de uma aplicação de cadastro comum. Primeiro, o formulário fica aberto ao público e coleta dados pessoais do consumidor — o que muda o padrão de segurança exigido na borda da aplicação. Segundo, campanhas desse tipo concentram acesso em janelas curtas de tempo: um anúncio ou uma ação de divulgação pode multiplicar o tráfego de um dia para o outro, e a infraestrutura precisa absorver isso sem que alguém precise provisionar servidor manualmente.

Decisões de arquitetura

O time já operava em PHP, e não havia motivo para trocar de linguagem só para resolver o problema de escala — o problema era de arquitetura de infraestrutura, não de linguagem. Mantive a stack do time e levei o backend para arquitetura serverless na AWS (AWS Lambda): a capacidade de processamento passa a acompanhar a demanda automaticamente, em vez de depender de um servidor dimensionado para o pior caso o tempo todo.

O front-end é publicado via AWS Amplify, o que simplifica a entrega contínua da interface de cadastro sem manter infraestrutura própria para isso.

Como o formulário é público e coleta dado pessoal, a proteção de borda não podia depender de uma única camada. Coloquei AWS WAF e Cloudflare em conjunto: duas camadas de filtro contra bots e tráfego malicioso antes de qualquer requisição chegar à aplicação. Em um cadastro aberto ao público, essa é a diferença entre uma campanha estável e uma campanha vulnerável a abuso automatizado logo no primeiro pico de divulgação.

Num cadastro público de dados pessoais, a arquitetura de borda não é um detalhe de infraestrutura — é parte do compromisso com quem está preenchendo o formulário.

Desafios & aprendizados

O maior aprendizado técnico foi confirmar, na prática, o motivo de escolher serverless para esse tipo de operação: uma campanha de curta duração não justifica manter capacidade ociosa o ano inteiro, e também não dá tempo de reagir manualmente a um pico. A arquitetura precisava absorver a variação sozinha, e foi isso que a combinação Lambda + Amplify entregou, sem exigir intervenção manual durante a campanha.

O outro aprendizado veio do lado do negócio, não da infraestrutura: a regra de elegibilidade aplicada automaticamente a cada cadastro precisava ser consistente entre milhares de avaliações, sem exceção caso a caso. O resultado disso aparece nos próprios números — a taxa de aprovação ficou estável em torno de 93% entre os cadastros avaliados, o que é um sinal de que os critérios estavam bem definidos e sendo aplicados de forma uniforme, não de decisão manual variando de analista para analista.

O dashboard em tempo real também mudou a forma como a gestão da campanha acompanhava o andamento: em vez de pedir um relatório para saber a situação, a informação de cadastros e vendas já estava disponível no momento em que era necessária.

Resultado

Com a plataforma em operação, o programa processou mais de 16 mil solicitações de cadastro, com mais de 14 mil clientes aprovados para participar — uma taxa de aprovação de cerca de 93%, com os demais 7% reprovados por não atenderem aos critérios do programa. A campanha rodou com alta demanda e nenhum incidente grave, sustentada pela combinação de arquitetura serverless com a proteção de borda em duas camadas.