TI para e-commerce: infraestrutura que não derruba suas vendas

Por que loja fora do ar custa mais caro do que parece

Todo minuto de indisponibilidade em um e-commerce tem preço direto: o carrinho abandonado, o pedido não fechado, o cliente que foi para o concorrente. Mas a conta real é maior. Quando a loja cai em horário de pico — uma quinta-feira à noite, uma campanha de e-mail que acabou de disparar, uma Black Friday — o prejuízo não é só a receita daquela hora. É o tráfego pago que continua rodando e queimando orçamento para levar visitantes a uma página de erro. É a posição no Google, que penaliza sites lentos ou instáveis. É a reputação, que leva meses para reconstruir depois de um "não consegui comprar no site de vocês" repetido em avaliações públicas.

A maioria dos gestores de e-commerce mede conversão, ticket médio e ROAS com precisão cirúrgica, mas não tem número nenhum sobre a disponibilidade da própria loja. Não sabem quantos minutos ficaram fora no último trimestre, nem quanto tempo o checkout levou para responder no último pico. Sem essa medição, a infraestrutura só aparece na conversa quando já quebrou — e aí a discussão é sobre culpa, não sobre solução.

Existe uma assimetria cruel aqui: o investimento em disponibilidade parece caro quando tudo está funcionando, e parece barato demais no dia em que a loja cai. O jeito de sair dessa armadilha é tratar infraestrutura como parte do funil de vendas, não como custo de TI. Um servidor que responde em 400ms em vez de 2 segundos converte mais. Um checkout que não falha em picos vende mais. Isso é performance comercial, medida em reais.

Disponibilidade: o que realmente sustenta uma loja no ar

Disponibilidade de verdade não vem de "um servidor bom". Vem de eliminar pontos únicos de falha em cada camada da operação. E a maior parte dos e-commerces brasileiros tem pelo menos três desses pontos ativos agora mesmo, geralmente sem saber: um único servidor de aplicação, um banco de dados sem réplica e um provedor de link único chegando ao datacenter.

A arquitetura mínima para uma loja que fatura sério envolve redundância em camadas. Aplicação distribuída atrás de um balanceador, banco de dados com réplica em standby pronta para assumir, links de internet de operadoras diferentes com failover automático, e uma CDN na frente absorvendo o tráfego de imagens e assets estáticos. Cada uma dessas peças resolve um modo de falha específico — e a ausência de qualquer uma delas transforma um incidente pequeno em uma queda completa.

• Redundância de aplicação: mais de uma instância servindo a loja, com health check ativo removendo automaticamente a que parou de responder.
• Réplica de banco: cópia sincronizada em outro host ou site, com procedimento de promoção testado — não apenas documentado.
• Link duplo com failover: operadoras distintas, roteamento com BGP ou failover no firewall, testado com desligamento real do link primário.
• CDN e cache de borda: reduz carga na origem em 60-80% e mantém páginas de catálogo servíveis mesmo com o backend degradado.
• Monitoramento sintético: robô que executa uma compra de teste a cada poucos minutos, do lado de fora, medindo o que o cliente realmente sente.

Esse último item é o mais negligenciado e o mais revelador. Monitorar CPU e memória do servidor diz que a máquina está viva. Não diz que o botão "finalizar compra" está funcionando. Um teste sintético que percorre home → produto → carrinho → checkout captura falhas de integração com gateway, certificado vencido e erro de aplicação que nenhum gráfico de infraestrutura mostraria.

Disponibilidade não se mede pelo uptime do servidor. Mede-se pela capacidade do cliente concluir a compra. São coisas diferentes, e só a segunda paga a conta.

Segurança de pagamentos e o peso do PCI DSS

Todo e-commerce que processa, armazena ou transmite dados de cartão está sob o escopo do PCI DSS — o padrão de segurança mantido pelas bandeiras. Muitos lojistas acreditam estar fora porque "quem processa é o gateway". Parcialmente verdade, e é justamente aí que mora o risco: a forma como a loja integra o gateway define o nível de exigência que recai sobre ela.

Se o checkout usa iframe ou redirecionamento hospedado pelo provedor de pagamento, o escopo cai drasticamente — o dado do cartão nunca toca a infraestrutura da loja. Se o formulário de cartão está na sua página e os dados trafegam pelo seu servidor antes de irem ao gateway, mesmo que não sejam armazenados, o escopo explode. A decisão de arquitetura tomada por um desenvolvedor há três anos pode ser a diferença entre um questionário simplificado e uma auditoria completa com pentest anual.

Independente do nível de escopo, existe um conjunto de controles que qualquer loja séria precisa manter — e que também é o que reduz risco de fraude e chargeback no dia a dia:

1. TLS atualizado e certificado monitorado: versões antigas de protocolo desabilitadas, e alerta automático 30 dias antes do vencimento. Certificado expirado derruba a loja inteira sem aviso.
2. Segmentação de rede: ambiente de pagamento isolado de rede administrativa, ERP e estações de trabalho. Um ransomware que entra pelo e-mail do financeiro não pode alcançar o servidor da loja.
3. Gestão de patches com prazo: vulnerabilidade crítica corrigida em dias, não em trimestres. A maioria dos incidentes explora falha conhecida com correção disponível há meses.
4. Controle de acesso individual e MFA: nada de credencial compartilhada em painel administrativo. Cada acesso com identidade própria e segundo fator, com log de quem fez o quê.
5. WAF na frente da aplicação: bloqueia injeção, tentativa de força bruta em login e varreduras automatizadas antes que cheguem ao código.
6. Retenção de logs: registro de acesso e transação guardado por período suficiente para investigar um incidente descoberto semanas depois.

Vale a lembrança de que segurança de pagamento e proteção de dados pessoais caminham juntas. A LGPD cobre nome, CPF, endereço e histórico de compra do cliente — dados que a loja armazena de qualquer jeito, mesmo terceirizando o cartão. Vazamento de base de clientes gera obrigação de notificação, exposição pública e sanção administrativa, sem que um único número de cartão tenha sido comprometido.

Performance: velocidade é conversão, não vaidade técnica

A relação entre tempo de carregamento e taxa de conversão é uma das mais bem documentadas do comércio digital. Cada segundo a mais na abertura da página derruba conversão de forma mensurável, e o efeito é mais forte no mobile, onde está a maior parte do tráfego brasileiro. Um e-commerce que carrega em 4 segundos não está apenas "um pouco mais lento" que um que carrega em 1,5 — está perdendo uma fatia relevante do faturamento todo mês.

Boa parte dos ganhos de performance não exige reescrever a loja. Vem de higiene de infraestrutura que costuma estar mal ajustada: imagens servidas em formatos modernos e dimensionadas corretamente, cache de página e de objeto configurado com invalidação inteligente, consultas lentas ao banco identificadas e indexadas, e assets estáticos entregues por CDN em vez de saírem da origem a cada requisição.

O ponto de atenção é que performance média engana. A loja pode ter tempo médio excelente e ainda assim estar perdendo vendas se o percentil 95 está ruim — ou seja, se 5% dos acessos levam 8 segundos. Esses 5% costumam ser justamente os momentos de pico, quando há mais gente comprando. Medir sempre por percentil, não por média, e testar carga antes de campanha grande, não durante.

Há ainda a dimensão de capacidade planejada. Uma campanha que multiplica o tráfego por dez não pode depender de "esperar dar problema para escalar". Saber com antecedência qual é o teto da infraestrutura atual, e ter caminho pronto para ampliar — seja com recursos elásticos em nuvem ou com capacidade reservada — é o que separa uma Black Friday lucrativa de uma noite de prejuízo com a loja intermitente.

Backup e recuperação: o plano que ninguém testa até precisar

Backup de e-commerce tem uma complicação que backup de escritório não tem: os dados mudam a todo instante. Restaurar o backup de ontem à noite significa perder todos os pedidos do dia, com clientes já cobrados e produtos já separados. A pergunta certa não é "temos backup?", é "quanto tempo de transação podemos perder e quanto tempo levamos para voltar?".

Esses dois números têm nome: RPO, o quanto de dado se aceita perder, e RTO, quanto tempo se aceita ficar fora. Definir os dois é decisão de negócio, não de TI — e é o que determina o desenho técnico. Um RPO de 15 minutos exige backup incremental frequente ou replicação contínua do banco. Um RTO de 1 hora exige ambiente de recuperação pré-provisionado e procedimento ensaiado, porque ninguém restaura, reconfigura e valida uma loja completa em uma hora improvisando.

A regra prática que sustenta isso é a 3-2-1: três cópias dos dados, em dois tipos de mídia diferentes, com uma delas fora do site principal e idealmente imutável. Cópia imutável importa muito no cenário atual de ransomware — o ataque moderno procura e apaga o backup antes de cifrar a produção, e uma cópia que não pode ser alterada nem pelo administrador é a última linha que sobra.

E o teste. Backup que nunca foi restaurado é hipótese, não garantia. Restauração precisa ser exercitada periodicamente em ambiente isolado, com verificação de que a loja sobe, o catálogo aparece e o checkout processa. Descobrir na madrugada de um incidente que o backup do banco estava corrompido há três semanas é um cenário comum — e inteiramente evitável com um teste trimestral de meia hora.

Como a Duk estrutura a TI de operações que vendem online

Em mais de 18 anos atendendo empresas brasileiras, a Duk Informática & Cloud construiu a prática de infraestrutura para e-commerce em cima de uma constatação simples: quase nenhuma queda de loja é causada por um evento imprevisível. São certificados que venceram, discos que encheram, backups que ninguém validou, links sem redundância e patches adiados. Problemas conhecidos, com solução conhecida, que só chegam à produção porque não havia ninguém acompanhando de forma contínua.

O trabalho começa por um diagnóstico honesto do que existe hoje — pontos únicos de falha mapeados, escopo de PCI DSS identificado conforme o modelo de integração do checkout, tempos reais de carregamento medidos por percentil e o RPO/RTO atual comparado com o que a operação de fato precisa. Desse levantamento sai um plano priorizado por risco e impacto em receita, não uma lista genérica de boas práticas. Como Microsoft Gold Partner, a Duk sustenta ambientes híbridos e em nuvem com licenciamento correto e integração com Microsoft 365 e Azure quando faz sentido para o cliente.

Depois vem a operação contínua: monitoramento sintético do fluxo de compra, gestão de patches com prazo definido, backup com teste de restauração agendado, resposta a incidente com SLA e um interlocutor técnico que conhece o ambiente — não um protocolo aberto em fila. São mais de 550 empresas atendidas com esse modelo, de operações que faturam alguns milhares por mês a ambientes com picos sazonais pesados. Se sua loja já teve uma queda que custou caro, ou se você simplesmente não sabe responder quantos minutos ficou fora no último trimestre, esse é o momento de conversar.