A stack de cache do WordPress que realmente sobrevive à Black Friday

Existe uma pergunta que todo site WordPress gerenciado acaba enfrentando: o que explode sob um pico de tráfego de 50×? A resposta curta geralmente é o banco de dados — não porque MySQL é ruim, mas porque cada camada de cache entre o visitante e o banco está mal configurada, ausente ou fazendo o trabalho errado.

Os quatro caches que importam

Um site WordPress em produção precisa de quatro camadas de cache, e a ordem importa:

1. Cache de edge — Cloudflare, BunnyCDN, CloudFront. Captura tráfego anônimo na borda da rede.
2. Cache de página — WP Rocket, W3 Total Cache, LiteSpeed Cache. Serve HTML completo do disco ou memória para hits anônimos repetidos.
3. Cache de objetos — Redis ou Memcached, via Object Cache Pro ou W3TC. Evita ida e volta ao MySQL para coisas como get_option(), get_transient() e leituras de sessão do WooCommerce.
4. Cache de opcode — PHP OPcache, configurado com opcache.validate_timestamps=0 em produção. Evita recompilar arquivos PHP em cada requisição.

Se você pula o cache de objetos, o MySQL vira o gargalo no momento em que o cache de edge erra. Se você pula o cache de opcode, o piso de CPU fica 2-3× maior do que precisa. Se você pula o cache de edge, vai pagar por cada bot que indexar seu site.

O que de fato configuramos

Para um site WooCommerce processando 100 mil pedidos mensais costumamos implantar:

• Cloudflare na frente, com tuning do cache HTML por rota (páginas de catálogo agressivas, bypass de carrinho/checkout por cookie)
• WP Rocket para cache de página, com WP_CACHE habilitado e cache em disco vivendo em volume SSD
• Redis com Object Cache Pro para cache de objetos (o plugin gratuito redis-cache funciona, mas o Pro é mais rápido sob contenção)
• OPcache com 256 MB alocados e opcache_reset() disparado a cada deploy
• Uma instância Redis separada para armazenamento de sessões do WooCommerce para que o checkout não brigue com outras leituras

O artigo completo no Medium cobre os arquivos de configuração reais, o hook de deploy que reseta cada camada, e os dashboards de monitoramento que colocamos por cima.