Você está no meio de uma migração de servidor. 3 da manhã. Um único comando rsync decide seu futuro. O banco de dados, um gigante de 20 GB, copia sem erros. A nova instância sobe. E aí, o inferno se instala.
Não, não é um ataque DDoS. Não é um pico de tráfego. É uma linha duplicada na tabela wp_options. Um registro siteurl com duas linhas idênticas. O cache de objeto, persistente, captura a primeira. O MySQL, em modo de alta concorrência, retorna a segunda aleatoriamente. Resultado? 503 em páginas de checkout. Usuários perdidos. Suporte pegando fogo.
Foi a pior noite da minha vida como engenheiro de infraestrutura. E o mais grotesco? A causa raiz não foi um bug no core, nem um plugin malicioso. Foi a Licença GPL.
O Erro Silencioso nas Entranhas do Core
WordPress, em sua sabedoria binária, update_option() é um dos gargalos mais subestimados. Em instalações headless, onde o banco é o único estado compartilhado, cada add_option irracional gera um deadlock latente. Mas e quando o próprio core gera duplicatas? Sim, acontece. Em versões específicas do WP 5.x, a função wp_load_core_site_options() tinha um bug de race condition: em requisições simultâneas, duas entradas idênticas para a mesma option key podiam ser inseridas.
Isso não está documentado em nenhum changelog oficial. É o que chamamos de ‘erro fantasma’: só aparece em ambientes reais, com cache desabilitado e alto paralelismo. E foi exatamente o que aconteceu conosco.
A GPL Não Te Protege de Você Mesmo
A beleza e a maldição da GPL: você pode modificar, distribuir, mas ninguém garante que seu fork não vai explodir. No nosso caso, um desenvolvedor, com as melhores intenções, havia aplicado um patch manual para acelerar o carregamento de opções via memcached. O patch quebrou a unicidade da chave siteurl. A GPL permitiu a modificação. Mas o suporte oficial do WordPress, baseado em GPL, nos mandou ‘procurar a comunidade’. Zero responsabilidade.
Eis a ironia: a liberdade da GPL pode gerar responsabilidade nenhuma. Para um SaaS que fatura milhões, isso é um tiro no pé. O ‘código aberto’ vira ‘código aberto e sangrando’.
O Impacto nos Core Web Vitals (Ou: Como Perdemos o Nosso LCP)
Com o banco corrompido, o Largest Contentful Paint (LCP) disparou. Cada requisição ao siteurl podia cair em um nó errado do CDN. O layout shift era grotesco: elementos de login apareciam em páginas de erro. O First Input Delay (FID) também sofreu, porque o loop de opções estava em lock spin waiting.
Nenhum teste automatizado capturou isso. Por quê? Porque os ambientes de staging não tinham o mesmo perfil de concorrência. O erro só emergia sob carga real, com 5000 usuários simultâneos. Foi um estresse de banco que nenhum script de benchmark prevê.
A Solução: Transações ACID em um Mundo eventualmente Consistente
Não, não adianta só deletar a duplicata. O problema é sistêmico. Implementamos um INSERT ... ON DUPLICATE KEY UPDATE em todas as chamadas de add_option. Parece óbvio, mas em instalações headless, com plugins que ignoram a API, é uma guerra. Forçamos transações com SELECT ... FOR UPDATE em operações críticas. Sim, perdemos um pouco de performance, mas ganhamos sanidade.
E a GPL? Continuamos usando. Mas agora temos um contrato interno: qualquer patch que toque em banco passa por revisão de três engenheiros. A liberdade requer disciplina. E, às vezes, um pouco de cinismo.
Headless WP e o Pesadelo das Opções
Em uma arquitetura headless, o banco de dados WordPress é o único ground truth. Sem renderização server-side, cada requisição REST ou GraphQL depende de opções corretas no primeiro hit. Uma duplicata no wp_options pode fazer um site headless retornar 404 em páginas que existem, simplesmente porque a rota foi mal resolvida. Já vi isso acontecer em um site de grande porte: a página inicial carregava em 500ms, mas qualquer post demorava 10 segundos. A causa? Uma option rewrite_rules com duas entradas, uma válida e uma corrompida.
E adivinhe? Não há log. O Apache só vê um 200, o Varnish cacheia o erro. O cliente só percebe quando a receita cai.
O Manifesto Técnico: Por Dentro do Inconsciente Coletivo
WordPress é um sistema operacional social. A GPL é a constituição. Mas constituições têm falhas. O erro que enfrentamos não é culpa de ninguém: é a entropia natural de um ecossistema que cresceu rápido demais. O que aprendi é que, como engenheiros, precisamos ser os guardiões do sono alheio. Não confie em unicidade que não é enforced pelo banco. Use chaves compostas. Monitore o wp_options como se fosse um canário em uma mina de carvão.
E, por favor, nunca ignore uma linha duplicada. Ela pode ser o fantasma que te assombra às 3 da manhã, enquanto você espera o restore de um backup que, ironicamente, também tem a duplicata.
- Verifique duplicatas:
SELECT option_name, COUNT(*) FROM wp_options GROUP BY option_name HAVING COUNT(*) > 1; - Force unique index:
ALTER TABLE wp_options ADD UNIQUE INDEX option_name (option_name);(mas teste antes, pois pode quebrar alguns plugins) - Desconfie de cache de objeto: Ele pode esconder o erro até ser tarde demais.
No fim, a GPL é sobre liberdade. E liberdade sem responsabilidade é só caos. Nosso site sobreviveu. O seu pode não sobreviver. Escolha suas batalhas com sabedoria. E, acima de tudo, nunca confie em um INSERT sem verificar antes.