Certa vez, durante um pico de tráfego em um portal de notícias, o site simplesmente parou. O banco de dados estava respondendo, o servidor web também. Mas as páginas não carregavam. O culpado? Um deadlock silencioso no Redis, o cache que deveria acelerar tudo. Headless WordPress é sexy, mas a verdade é que a maioria dos setups ignora o monstro escondido no estado de transação do Redis. Vamos cavar fundo nesse conflito de banco de dados que pode destruir suas Core Web Vitals.
O Cenário do Headless: Promessas e Armadilhas
Headless WordPress separa o backend do frontend. O backend vira uma API; o frontend consome dados via REST ou GraphQL. Para performance, entra o Redis como cache de objetos e de páginas. Lindo no papel. Na prática, o caldo entorna quando múltiplas requisições tentam set e get simultaneamente.
O Deadlock de Transação: A Morte Silenciosa
Imagine: uma requisição A faz SET key:1 value e trava a chave. Ao mesmo tempo, requisição B faz SET key:2 value e trava outra. A precisa de B para terminar, B precisa de A. Deadlock. No Redis, isso é raro, mas em configurações com transactions (MULTI/EXEC) e watch, pode acontecer. O pior: o site não dá erro claro. Apenas fica lento, depois para.
O Estudo de Caso Reverso: Um Portal de Notícias em Crise
Um cliente com alto tráfego usava Headless WP com Redis para cache de consultas na home page. Em dias de pico, as transações de cache competiam por chaves bloqueadas. O deadlock não era detectado pelo WordPress. Resultado: tempo de resposta subiu de 200ms para 30s. As Core Web Vitals (LCP) dispararam para 15s. O Google penalizou o site. A causa? Um conflito de lock mal configurado no Redis.
A Anatomia do Conflito
O WordPress usa transações no Redis para atomicidade. Quando duas requisições tentam modificar a mesma chave com WATCH, uma falha. O problema é que, em headless, muitas requisições são geradas por um único usuário (várias partes da página). Se o Redis não tratar retry adequadamente, o deadlock de transação se instala.
Solução comum? Aumentar timeout. Erro! Isso só mascara. A solução real é implementar locks distribuídos com SETNX e expiry. Ou usar pipeline sem transações. Mas a maioria dos plugins de cache para Headless WP não faz isso.
Impacto nas Core Web Vitals
O LCP depende do servidor responder rápido. Um deadlock no Redis segura a resposta por segundos. O FID também sofre, pois o JavaScript que depende de dados do cache demora a executar. O CLS pode piorar com carregamento assíncrono atrasado.
Mitigação Real (Além dos Artigos Genéricos)
1. Monitore o Redis com MONITOR em picos. 2. Use client que suporte retry automático com jitter. 3. Configure max-retries e backoff exponencial. 4. Evite transações MULTI/EXEC em operações de cache; prefira pipeline simples. 5. Para casos extremos, use Redis Cluster com replicação, mas cuidado com split-brain.
Headless WordPress é poderoso, mas esquece que um conflito de banco de dados no Redis é como uma hemorragia interna: só percebe quando o colapso chega. Core Web Vitals não perdoam. E o pior: a documentação oficial do WordPress mal toca nesse deadlock de transação. Fica o alerta de um insider que já viu sites gigantes caírem por isso.