Seu sistema aguenta a Black Friday? Como garantir alta disponibilidade e resiliência

Em novembro de 2023, uma grande varejista brasileira perdeu aproximadamente R$ 4 milhões em vendas em menos de duas horas. O motivo? O sistema de checkout não aguentou o pico de acessos da Black Friday e simplesmente caiu. Enquanto o time de TI corria para restaurar o serviço, os concorrentes convertiam os clientes que haviam migrado para outros sites. Não foi um problema de produto, de preço ou de marketing. Foi um problema de arquitetura.

Esse cenário se repete todo ano, em empresas de todos os tamanhos. E o mais frustrante é que ele é quase sempre evitável. A Black Friday não é uma surpresa. A data é conhecida com meses de antecedência. O volume de acesso é previsível dentro de uma faixa razoável. E ainda assim, sistemas caem, carrinho some, pagamento trava. Por quê? Porque a maioria das empresas trata resiliência como um projeto futuro, não como uma propriedade fundamental da arquitetura.

Neste artigo, vou compartilhar as estratégias que aplico com meus clientes — incluindo empresas do setor financeiro como BTG, XP e Inter — para garantir que seus sistemas não apenas sobrevivam à Black Friday, mas performem com excelência durante ela.

O problema não é o tráfego. É a arquitetura que não foi feita para variar

Quando um sistema cai em picos de acesso, o instinto é culpar o volume. "Recebemos 10x mais acessos do que o normal." Mas essa explicação esconde o problema real: uma arquitetura que foi projetada para um estado estável e nunca foi testada para variação.

Sistemas monolíticos, bancos de dados sem estratégia de leitura distribuída, filas síncronas e dependências em cascata são os culpados mais comuns. Quando uma parte do sistema fica sobrecarregada, ela não apenas degrada — ela derruba tudo ao redor. É o efeito dominó da arquitetura mal planejada.

A primeira pergunta que faço quando avalio um sistema antes de um grande evento é: onde estão os single points of failure? Todo sistema tem pontos críticos. A diferença entre um sistema resiliente e um frágil é se esses pontos foram identificados, isolados e protegidos com redundância e mecanismos de fallback.

Um cliente do setor de fidelidade, que processa milhões de pontos diariamente, chegou até mim com exatamente esse problema. O sistema funcionava perfeitamente em condições normais, mas qualquer pico de campanha derrubava o serviço de consulta de saldo. A solução não foi apenas aumentar a capacidade do servidor — foi redesenhar o fluxo para que a consulta de saldo se tornasse independente do processamento de transações, com camadas de cache e circuit breakers adequados.

Escalabilidade não é sinônimo de "adicionar mais servidores"

Existe uma confusão muito comum no mercado entre escalabilidade e capacidade bruta. Escalar horizontalmente na AWS não significa simplesmente ligar mais instâncias EC2. Significa projetar o sistema para que cada componente possa crescer de forma independente, sem criar gargalos em outros pontos.

Na prática, uma arquitetura resiliente para picos como a Black Friday precisa de pelo menos quatro camadas bem resolvidas:

• Camada de entrada: uso de CDN (como CloudFront) para absorver tráfego estático e reduzir a carga nos servidores de aplicação. Em alguns casos, até 60% do tráfego pode ser servido direto do edge, sem tocar na sua infraestrutura de backend.
• Camada de aplicação: serviços desacoplados com auto scaling configurado com políticas baseadas em métricas reais de negócio — não apenas CPU, mas latência de resposta, profundidade de fila e taxa de erros.
• Camada de dados: separação entre leitura e escrita, uso de réplicas de leitura no RDS ou Aurora, e estratégia de cache com ElastiCache para consultas de alta frequência e baixa variabilidade.
• Camada de integração: uso de filas assíncronas (SQS, SNS, EventBridge) para desacoplar processos críticos como confirmação de pedido, atualização de estoque e comunicação com sistemas de pagamento.

Essa separação parece óbvia no papel, mas na prática a maioria dos sistemas que avalio tem pelo menos duas dessas camadas acopladas de forma que uma degrada a outra sob pressão. O checkout depende diretamente do sistema de estoque em tempo real. O sistema de estoque consulta o banco principal a cada requisição. O banco principal não tem índices adequados para o volume de leitura simultânea. E quando o checkout trava, ninguém sabe exatamente por quê.

O papel do chaos engineering e dos testes de carga

Não existe resiliência sem teste. Essa é uma das afirmações mais simples e mais ignoradas na engenharia de plataformas. Empresas investem meses construindo arquiteturas redundantes e nunca validam se a redundância realmente funciona quando é necessária.

O chaos engineering — popularizado pelo Netflix com o Chaos Monkey — parte de um princípio direto: se você não introduzir falhas controladas no seu sistema antes que o ambiente de produção o faça, você está operando com uma falsa sensação de segurança. Na AWS, o serviço Fault Injection Simulator (FIS) permite simular falhas de instância, latência de rede, falha de zona de disponibilidade e outros cenários de degradação de forma controlada.

Com clientes do setor financeiro, onde a disponibilidade não é apenas uma métrica de experiência do usuário mas uma obrigação regulatória, os testes de caos são parte do ciclo de desenvolvimento. Não é opcional. Antes de qualquer evento de alto volume — seja uma Black Friday, um IPO ou uma campanha de grande escala — rodamos cenários de falha para validar que os mecanismos de recuperação automática funcionam dentro dos SLAs definidos.

Os testes de carga, por sua vez, precisam ser mais sofisticados do que simplesmente disparar mil requisições simultâneas e ver o que acontece. O tráfego da Black Friday tem um perfil específico: há um crescimento gradual nas horas anteriores, um pico abrupto na virada da meia-noite ou no início de promoções relâmpago, e um comportamento de usuário diferente do cotidiano — mais comparação de preços, mais abandono de carrinho, mais tentativas de pagamento. Simular esse perfil realista faz toda a diferença na qualidade do teste.

Disaster recovery não é backup. É uma estratégia com RTO e RPO definidos

Um dos equívocos mais caros que vejo em empresas de médio porte é confundir backup com disaster recovery. Backup é uma cópia dos seus dados. Disaster recovery é a capacidade de retomar operações dentro de um tempo e com uma perda de dados aceitáveis para o negócio.

Dois conceitos são fundamentais aqui: RTO (Recovery Time Objective) — quanto tempo você pode ficar fora do ar antes de o impacto ser inaceitável — e RPO (Recovery Point Objective) — até quando você pode perder dados sem consequências graves. Para um e-commerce na Black Friday, um RTO de 4 horas pode representar dezenas de milhões em receita perdida. Para um banco, um RPO de 1 hora pode ter implicações regulatórias sérias.

A AWS oferece diferentes estratégias de DR com trade-offs claros entre custo e velocidade de recuperação: Backup and Restore (mais barato, mais lento), Pilot Light (infraestrutura mínima sempre ligada), Warm Standby (capacidade reduzida sempre disponível) e Multi-Site Active/Active (máxima disponibilidade, maior custo). A escolha certa depende do perfil de criticidade de cada serviço — e a maioria das empresas não faz essa segmentação. Trata tudo como se tivesse o mesmo nível de criticidade, o que resulta em ou gastar mais do que precisa ou estar desprotegido onde mais importa.

Observabilidade: você não pode proteger o que não consegue enxergar

Durante um pico de tráfego, a velocidade de detecção de problemas é tão importante quanto a velocidade de recuperação. Um sistema que cai silenciosamente — sem alertas, sem dashboards, sem correlação de logs — pode levar 20 ou 30 minutos para que alguém perceba o problema. Em uma Black Friday, esses minutos são ouro.

Observabilidade não é apenas monitoramento. É a capacidade de entender o estado interno do sistema a partir dos sinais que ele emite: métricas, logs e traces distribuídos. O modelo dos três pilares — consolidado pelas ferramentas do ecossistema AWS como CloudWatch, X-Ray e OpenTelemetry — permite que você não apenas saiba que algo está errado, mas entenda onde e por quê.

Um exemplo prático: em um sistema de pagamentos que acompanhei, o tempo médio de resposta estava dentro do SLA, mas a taxa de erros estava subindo gradualmente. Sem observabilidade granular, isso poderia passar despercebido até virar uma crise. Com traces distribuídos, identificamos em menos de três minutos que o problema estava em uma dependência externa de antifraude que estava degradando sob carga — não no sistema principal. A correção foi ativar um fallback que já estava previsto na arquitetura, mas que nunca havia sido acionado antes.

Dashboards operacionais para eventos de alto volume devem mostrar, em tempo real: taxa de erros por serviço, latência por percentil (p95, p99), throughput de transações, profundidade de filas assíncronas e status de cada zona de disponibilidade. Qualquer desvio significativo precisa gerar alertas proativos, não reativos.

O checklist que uso antes de qualquer grande evento

Depois de mais de 20 anos trabalhando com arquitetura de sistemas e de ter acompanhado de perto dezenas de Black Fridays, IPOs e campanhas de alto volume, consolidei um checklist operacional que aplico com meus clientes. Não é exaustivo, mas cobre os pontos de maior risco:

• Todos os auto scaling groups estão com políticas testadas e limites de capacidade revisados?
• O banco de dados tem réplicas de leitura ativas e o pool de conexões está dimensionado para o pico esperado?
• O cache está aquecido com os dados de maior frequência de acesso?
• Os circuit breakers estão configurados em todas as integrações externas?
• Os testes de carga foram executados com um perfil de tráfego realista nas últimas duas semanas?
• O runbook de incidentes está atualizado e a equipe de plantão sabe exatamente o que fazer em cada cenário de falha?
• Os limites de rate limiting e proteção contra DDoS estão configurados no WAF e no CloudFront?
• O processo de rollback rápido foi testado para as últimas versões deployadas?

Cada item desse checklist representa uma falha que já vi acontecer em produção. Nenhum deles é trivial de implementar, mas todos são gerenciáveis quando abordados com antecedência suficiente.

Resiliência é uma decisão de negócio, não apenas técnica

O que mais me incomoda quando discuto esse tema com líderes de empresas é a percepção de que resiliência é um custo de infraestrutura, não um investimento de negócio. Essa visão é equivocada e cara.

Quando você calcula o custo de uma hora de indisponibilidade durante a Black Friday — receita perdida, custo de recuperação, impacto na reputação da marca, possível churn de clientes — e compara com o custo de uma arquitetura resiliente bem projetada, a conta sempre fecha a favor da resiliência. O problema é que o custo da falha aparece em uma linha e o investimento em prevenção aparece em outra, e raramente quem aprova orçamento conecta os dois.

O papel do CTO, do CIO e do conselheiro de tecnologia é precisamente fazer essa conexão explícita. Traduzir risco técnico em risco de negócio. Mostrar que a escolha não é entre gastar ou não gastar, mas entre gastar de forma planejada agora ou gastar de forma emergencial — e muito mais cara — durante uma crise.

A Black Friday de 2025 está no horizonte. A infraestrutura que vai suportá-la precisa ser projetada, testada e validada antes disso. Se você está lendo este artigo em abril, ainda há tempo. Se está lendo em outubro, o tempo está acabando. De qualquer forma, a pergunta que precisa ser respondida é a mesma: você sabe, com certeza, onde seu sistema vai ceder sob pressão? Se a resposta for não — ou se for um "provavelmente não" pouco convincente —, esse é o ponto de partida.