O WordPress® não opera isoladamente. Os sites frequentemente se conectam a CRMs externos, sistemas ERP, gerenciadores de estoque, gateways de pagamento e APIs de atendimento. Embora essas integrações possam agregar valor, também introduzem vulnerabilidades estruturais.
O risco não se limita apenas à possibilidade de um serviço de terceiros ficar fora do ar e causar a falha de uma funcionalidade específica. O verdadeiro perigo reside em uma falha em cascata. Se uma API externa apresentar latência ou ficar completamente offline, um site WordPress mal isolado pode ser completamente comprometido.
O servidor não falhará devido a problemas no banco de dados ou falta de memória. A falha ocorrerá porque os trabalhadores do PHP-FPM no servidor estão presos em uma fila síncrona, aguardando uma resposta que não chega.
Um site verdadeiramente resiliente utiliza isolamento defensivo de código. A seguir, estão as diretrizes para desvincular a disponibilidade do frontend do seu site da confiabilidade das dependências de terceiros.
A Anatomia de um Travas de Trabalhador PHP
Quando um serviço externo falha ou desacelera sob carga pesada, muitos desenvolvedores acreditam que o impacto é restrito àquela função específica. Pensam que, se o API do calculador de frete estiver lento, apenas a página de checkout terá atrasos.
Para compreender por que essa é uma suposição perigosa, é necessário examinar como o PHP e seu servidor lidam com o tráfego de entrada.
Por padrão, as requisições HTTP realizadas através de funções básicas do WordPress, como wp_remote_get() ou wp_remote_request(), são síncronas e bloqueantes. O PHP é inerentemente de thread única. Quando um processo de trabalhador executa uma requisição HTTP bloqueante, ele interrompe completamente a execução e fica inativo, aguardando a resposta do servidor externo.
[Requisição de Entrada] ➔ [Trabalhador PHP-FPM Atribuído] ➔ [Executa wp_remote_get()] ➔ [Trabalhador Parado / Aguardando API]
A maioria dos servidores de produção utiliza um gerenciador de processos como PHP-FPM, que tem um número finito de trabalhadores (por exemplo, de 20 a 50 trabalhadores simultâneos, dependendo da configuração do servidor). Se seu site enfrentar um pico repentino de tráfego e 20 usuários simultâneos acessarem uma página que aciona uma chamada lenta à API de terceiros, todo o seu pool de trabalhadores pode ser esgotado instantaneamente.
Nesse momento, seu servidor estará no limite. O 21º visitante será colocado em uma fila, mesmo que esteja tentando acessar uma homepage estática e textual que não utiliza a API. Quando a fila se enche, o Nginx ou Apache emitirá um erro 502 Bad Gateway ou 504 Gateway Timeout. Um ponto de extremidade de API lento em uma única página profunda causou a queda de toda a rede.
O Perigo do Cache e as Stampedes de Cache
Uma defesa comum contra gargalos de APIs é o cache da resposta externa utilizando a API de Transientes do WordPress. Ao envolver sua requisição em get_transient() e set_transient(), você garante que seu servidor acesse a API externa apenas uma vez a cada hora ou dia, em vez de em cada carregamento de página.
Embora o cache seja essencial, depender apenas de transientes padrão sob alta carga cria uma vulnerabilidade grave conhecida como “stampede de cache”.
Considere uma loja de eCommerce de alto tráfego onde um transiente da API expira. No exato milissegundo, 50 usuários simultâneos acessam o site. Como get_transient() retorna falso para todos os 50 trabalhadores ao mesmo tempo, cada um deles executará wp_remote_get() para atualizar o cache.
Em vez de proteger a API externa e seu servidor local, você acabou de gerar um enorme pico sincronizado de requisições externas! Se a API de terceiros responder lentamente durante essa stampede, seu pool de trabalhadores travará instantaneamente, e o site irá falhar.
Como Prevenir a Stampede: Bloqueio de Transientes
Para resolver a stampede de cache, precisamos introduzir um bloqueio de transiente.
Quando o cache principal expira, o primeiro trabalhador PHP que notar a falta de dados definirá imediatamente um transiente de ‘bloqueio’ temporário (por exemplo, por 30 segundos). Quando os outros 49 trabalhadores simultâneos verificarem o cache e encontrarem vazio, também verão o bloqueio. Isso informa que “alguém já está buscando os dados!” Em vez de sobrecarregar a API externa, esses 49 trabalhadores retornarão imediatamente seus dados de fallback, neutralizando completamente a stampede.
Roteamento Defensivo: Ajustando Suas Requisições HTTP
A primeira regra da engenharia defensiva é nunca aceitar valores de configuração padrão sem questionar. Por padrão, o WordPress define um tempo limite de 5 segundos para requisições HTTP realizadas via wp_remote_get(). Cinco segundos é uma eternidade. Se um trabalhador travar por 5 segundos em um site de alto tráfego, a exaustão de recursos é praticamente garantida.
Ao se comunicar com APIs externas no frontend, você deve reduzir agressivamente seus tempos limites e tratar os erros resultantes de forma graciosa usando is_wp_error().
A seguir, um exemplo de como configurar um wrapper defensivo para uma chamada de API:
Ao reduzir o tempo limite para 1,5 segundos, você garante que uma API falhando possa prender um trabalhador PHP por apenas um breve momento, dando ao seu servidor uma chance de reciclar esse trabalhador e atender à próxima requisição.
Implementando o Padrão do Disjuntor
Reduzir os tempos limites protege seu pool de trabalhadores de longos travamentos, mas não evita que seu servidor continue tentando acessar uma API quebrada ou offline. Se um serviço externo ficar fora do ar por uma hora, seu servidor ainda gastará 1,5 segundos em cada carregamento de página tentando acessá-lo.
Para resolver isso, podemos adotar uma estratégia clássica de arquitetura de microsserviços: o Padrão do Disjuntor.
O conceito é simples:
- Circuito Fechado: A API está funcionando normalmente; as requisições fluem.
- Circuito Aberto (Desarmado): A API falhou várias vezes consecutivas. O circuito “desarma” e seu código para de tentar acessar a API remota, retornando imediatamente os dados de fallback sem desperdiçar recursos do servidor.
- Meio Aberto: Após um período de resfriamento, o circuito permite uma única requisição para testar se o serviço externo se recuperou.
Podemos implementar um disjuntor leve e altamente eficaz nativamente no WordPress utilizando a API de Cache de Objetos ou os Transientes:
Com essa arquitetura, se um parceiro de terceiros sofrer uma interrupção, seu site tentará se conectar a eles apenas 3 vezes. Na terceira falha, o circuito se desarma. Nos próximos cinco minutos, seu site não gastará um único milissegundo esperando por essa API, mantendo seu frontend rápido e completamente isolado da interrupção.
Após esses cinco minutos, é onde entra o estado Meio Aberto. Observe que no código não deletamos o contador de falhas quando o circuito se desarma; fazemos isso apenas em uma resposta bem-sucedida. Após a expiração do $circuit_status_key, o circuito se torna “Meio Aberto” e permite uma única requisição para testar a API. Se essa requisição falhar, o contador de falhas aumenta de 3 para 4, desarmando imediatamente o circuito por mais 5 minutos sem forçar o servidor a esperar por 3 novas falhas. Se for bem-sucedida, o contador é deletado e o circuito se fecha completamente.
Cuidado com a Condição de Corrida
O código do disjuntor acima depende de get_transient() e set_transient() para contar falhas. Embora isso funcione bem para configurações padrão, introduz uma condição de corrida em sites de tráfego extremamente alto.
Como os transientes não são atômicos, se 10 usuários acionarem um tempo limite de API exatamente no mesmo milissegundo, todos os 10 trabalhadores PHP podem consultar simultaneamente o banco de dados, ler a contagem de falhas como 0 e todos sobrescreverem a contagem para 1. Isso pode levar mais tempo do que 3 falhas reais para desarmar o circuito.
Se seu servidor estiver executando um cache de objetos persistente como Redis ou Memcached, evite a API de Transientes para o contador. Em vez disso, utilize a função nativa wp_cache_incr() do WordPress. Isso realiza um incremento atômico diretamente na RAM do servidor, garantindo uma contagem de falhas perfeitamente precisa, independentemente do tráfego concorrente.
Conclusão
Confiar em serviços externos é uma necessidade, mas permitir que esses serviços determinem a disponibilidade do seu site é uma escolha arquitetônica.
Ao envolver requisições HTTP em padrões defensivos, como a redução de tempos limites bloqueantes, o planejamento contra stampedes de cache e a implementação de disjuntores que falham rapidamente, você assegura que um desastre de terceiros permaneça como um erro isolado em uma funcionalidade específica, em vez de uma queda catastrófica em todo o site.
Fonte: Delicious Brains
