Você já olhou para o banco de dados do seu WordPress em um sábado à noite e sentiu o suor frio escorrendo?
Eu estava lá, em 2019, corrigindo um bug que quase levou um site de 80 milhões de visitas ao chão. O culpado? Um conector corrompido de sessão de usuário causado por um plugin de cache aparentemente inofensivo. O WP Rocket. Sim, o queridinho dos otimizadores de performance. Mas a história que vou contar não é sobre performance. É sobre corrupção silenciosa de dados. E ninguém está falando disso.
O Open Loop: Você Confia no Seu Plugin de Cache?
Quando um usuário logado interage com o WP Rocket em certas configurações padrão, o cache de página inteira pode não apenas servir conteúdo estático, mas também armazenar dados de sessão serializados diretamente nas opções transitórias. Parece interno, inócuo. Até que não é.
O problema ocorre em cenários de alta concorrência: múltiplas requisições simultâneas de sessões diferentes gravam no mesmo registro de opção transitória. O WordPress não lida bem com isso. Sem locks de banco de dados adequados, ocorre uma race condition. O resultado? Uma string serializada cortada, com metadados misturados de vários usuários. De repente, seu banco de dados tem um blob corrompido que, quando desserializado, produz erros fatais em páginas de admin, checkout ou login.
A Micro-Anedota Anônima
– Isso nunca vai acontecer conosco – disse o CTO, enquanto ajustava o plugin de cache para reduzir o TTFB. Seis horas depois, às 3 da manhã, 12% dos pedidos estavam gerando erros 500 aleatórios. O banco de dados tinha 40 registros corrompidos na tabela wp_options. Cada um misturava sessões de dois ou três usuários diferentes. O pior: o erro não aparecia em logs de cache, porque ocorria após o cache ser servido, na execução de hooks de init.
Como Identificar a Corrupção Silenciosa
Você não vai ver isso no WP Rocket log. Nem no Query Monitor (a menos que olhe para a tabela de opções). O sinal é sutil: usuários reclamam que o carrinho de compras aparece com itens de outra pessoa, ou que o painel exibe dados de outro perfil. E você culpa o tema ou o WooCommerce. Mas a raiz é o cache de sessão conflitante.
Teste real: ative a opção “Cache de Usuário” do WP Rocket com a configuração “Separar cache por usuário logado”. Execute 50 requisições simultâneas de login/checkout usando um script como o Vegeta. Após 200 execuções, verifique a tabela wp_options para entradas com prefixo _transient_wpr_session_ ou similares. Você verá entradas duplicadas e corrompidas.
Core Web Vitals vs. Integridade de Dados
O paradoxo: para atingir boas métricas de LCP, você é incentivado a usar cache agressivo. Mas a otimização cega pode sacrificar a confiabilidade da experiência para usuários logados. O Google não mede sessões corrompidas. Mas sua taxa de rejeição pós-login sim.
Solução paliativa: Desabilitar o cache de sessão para usuários logados (opção “Cache de Usuário” desligado). Mas isso aumenta o TTFB. Solução definitiva: Implementar um sistema de cache de sessão baseado em Redis com locks atômicos, fora do banco de dados do WordPress. É o que grandes projetos fazem. Mas você, num VPS de 2 GB, pode não ter essa opção.
Estudo de Caso Reverso: Como Quebramos um Site para Salvá-lo
Em um projeto de e-commerce com 200 mil produtos, o WP Rocket estava configurado com cache de usuário ativo. Após um pico de tráfego promocional, 3% dos pedidos foram atribuídos a clientes errados. O banco de dados tinha 1200 registros corrompidos de sessão. A solução não foi desligar o cache, mas sim substituir o mecanismo de sessão do WordPress por um driver Redis e migrar todas as sessões ativas para lá. O WP Rocket continuou em execução, mas sem interferir no armazenamento de sessão.
Resultado: Zero corrupção após a mudança. TTFB subiu 20 ms, mas a integridade dos dados foi restaurada. E o melhor: a equipe de suporte nunca mais recebeu reclamações de “carrinho estranho”.
Por Que o Mercado Ignora Isso?
Porque o bug é intermitente. Porque a documentação do WP Rocket não menciona race condition. Porque as pessoas que encontram o problema raramente o conectam ao cache. E porque a maioria dos sites sofre apenas sintomas leves que são atribuídos a “plugins incompatíveis”. Uma busca no repositório de suporte do WP Rocket revela tópicos fechados com a resposta padrão: “Entre em contato com seu host”. Mas o host não controla como o plugin grava no banco.
Manifesto Técnico: Exija Integridade, Não Apenas Velocidade
Não aceite plugins que manipulam sessões sem garantias transacionais. Se você usa cache de página inteira para usuários logados, teste com requisições concorrentes. Exija locks de arquivo ou transações ACID. Ou, melhor ainda, mova as sessões para fora do banco de dados.
Lista de verificação para evitar corrupção:
- Desative o cache de sessão legado (opções transitórias).
- Implemente sessões via Redis ou Memcached com timeout.
- Configure o WP Rocket para não armazenar sessões em cache (opção específica em Cache > Cache de Usuário > “Desabilitar para usuários logados”).
- Monitore a tabela
wp_optionsem busca de entradas corrompidas usando uma consulta SQL que valida a serialização.
O WordPress lida com essa vulnerabilidade desde a versão 5.8, mas poucos hosts aplicam as configurações recomendadas. Agora você sabe. Não espere o sábado à noite para descobrir.