Plataforma de campanhas de alto tráfego
Plataforma de campanhas e participação de usuários, com picos de acesso concentrados em janelas curtas e prazo de campanha inegociável.
Case anonimizado: nomes de cliente, dados de infraestrutura e detalhes sensíveis foram omitidos por confidencialidade.
Contexto
Plataforma digital de campanhas e participação de usuários. O padrão de carga é o oposto do tráfego constante: longos períodos de calmaria seguidos de picos concentrados quando uma campanha vai ao ar.
Desafio
Uma campanha tem data e hora marcadas. Se a plataforma cai no pico, não existe segunda chance. O prazo é do negócio, não da engenharia. O sistema precisa absorver o pico ou degradar de forma controlada.
Meu papel
Senior Software Engineer, com foco em performance de backend, serviços Node.js, banco de dados e resposta a incidentes.
Responsabilidades
- Performance de backend sob carga concentrada.
- Serviços em Node.js.
- Consultas e modelagem em MongoDB.
- Monitoramento, uptime e resposta a incidentes.
Restrições
- Prazos de campanha inegociáveis e divulgados publicamente.
- Carga altamente irregular: dimensionar para o pico é caro, dimensionar para a média é falhar.
- Falha durante a campanha é visível para o usuário final e para o cliente.
Arquitetura
- Cache nos caminhos de leitura mais quentes, para que o pico não chegue todo ao banco.
- Revisão das consultas no caminho crítico de participação.
- Roteamento e supervisão dos processos Node.js.
- Monitoramento com atenção especial às janelas de campanha.
Principais decisões técnicas
Otimizar o caminho crítico de leitura antes de escalar infraestrutura.
Por quê
Escalar máquina para compensar consulta ruim multiplica o custo e apenas adia o problema. O caminho de participação é curto e conhecido, e dava para torná-lo barato.
Trade-offs
- Trabalho de otimização é mais lento que subir instâncias.
- Cache introduz a questão da invalidação, que precisa ser resolvida explicitamente.
- O ganho, porém, permanece depois que o pico passa.
Implementação
- Ajustes de performance em serviços Node.js.
- Revisão de consultas e índices em MongoDB.
- Camada de cache nos endpoints de maior acesso.
Operação em produção
- Acompanhamento em tempo real durante as janelas de campanha.
- Resposta a incidentes com a campanha no ar.
- Monitoramento de uptime como métrica de negócio, não apenas técnica.
Resultados
- Sustentou a operação da plataforma durante picos de campanha.
- Reduziu a carga que chegava ao banco nos endpoints mais acessados.
- Tornou os incidentes durante campanha diagnosticáveis a partir de monitoramento, e não de tentativa e erro.
Stack
- Node.js
- MongoDB
- NGINX
- Redis
- Linux