Verificar backlinks de páginas por meio de uma API e fazer cache de forma honesta
Nosso índice é atualizado uma vez por mês, então a maioria das consultas pode ser servida a partir da memória. Uma receita para caches que economizam créditos sem mostrar aos usuários dados desatualizados.
Equipe editorial AlfaLinks ·
A regra
Faça cache até a próxima atualização do índice, não por um número fixo de horas
Como os dados mudam aproximadamente uma vez por mês, um TTL por hora não traz benefícios, apenas custos. Uma chave com escopo mensal fornece a mesma resposta durante todo o mês e é invalidada de uma só vez.
Chave: ação + domínio + parâmetros + mês do índice
TTL: até o final do mês, mais um dia de carência
Nunca faça cache de uma resposta de erro
Por que um TTL curto é apenas uma doação para o seu saldo de créditos
Equipes novas em dados de links copiam hábitos de rastreadores de posição. Hábito um: cache por hora, porque as posições mudam. Os grafos de links mudam pouco.
Uma chamada backlinks de 2 créditos custa $0.0002. Isso parece pouco até uma lista de visualizações disparar 50 delas por carregamento de página em 400 workspaces ativos, repetindo a cada hora para respostas idênticas.
Os números trabalhados abaixo são um exemplo, não uma medição do tráfego de ninguém. Suponha 400 workspaces, 20 visualizações de domínio por dia, 2 créditos por visualização e um cache de 1 hora que acerta talvez uma quinta parte das vezes. A maioria das visualizações ainda atinge a API. Com uma chave mensal, o mesmo tráfego atingiria a API apenas uma vez por domínio e mês, então a diferença é o ponto central da receita.
Ferramentas de pesquisa de palavras-chave precisam de dados mais recentes, e para isso as grandes suítes continuam sendo a melhor escolha. Para contexto de links, mensal é o produto.
TTL por ação
Sugerido, não obrigatório. Todas as ações leem o mesmo índice mensal.
Ação
Créditos
TTL sugerido
Por que
visão geral, estatísticas
0
Até o final do mês
Grátis, mas seu servidor ainda economiza latência
bulk_dr
1
Até o final do mês
Tabela inteira do cliente em uma chamada
refdomains, backlinks
2
Até o final do mês, por parâmetro de página
Inclua page, per, sort na chave
anchors, toppages
2
Até o final do mês
Estável entre atualizações
search, keyword
3
7 dias
Raramente repetido, barato pular o cache
Exemplo de requisição: aquecer o cache para uma tabela de clientes
Chame bulk_dr uma vez por cliente, não uma vez por linha. Até 2.000 domínios cabem em um único corpo POST e custam um crédito.
bash
curl -X POST "https://alfalinks.net/api.php?action=bulk_dr&key=sk_live_..." \
-d "domains=stripe.com,notion.so,linear.app,figma.com,vercel.com"
# billed once, whatever the row count
Construa o cache em cinco etapas
Cada etapa tem um trabalho. Pule uma e a falha aparecerá mais tarde, geralmente como uma conta.
01
Escolha a chave
Use a ação, o domínio, os parâmetros de paginação e ordenação, e o mês do índice. Deixe de fora qualquer coisa que o usuário possa alterar sem mudar a resposta, como uma cor de exibição ou um nome de aba.
02
Armazene a resposta analisada
Mantenha o JSON decodificado com sua flag ok e dados, não os bytes brutos. Uma visualização posterior pode então reconstruir toda a tabela a partir da memória sem uma segunda chamada.
03
Expirar no final do mês
Defina a expiração para o final do mês do índice, mais o dia de carência da regra acima. Use a mesma regra para todas as ações, para que a lógica viva em uma função e não em cinco lugares.
04
Registre o saldo em cada chamada
Leia o objeto _credits em cada resposta autenticada e grave o saldo restante no seu próprio log. Uma queda lenta nessa linha é frequentemente o primeiro sinal de que uma chave de cache está errada.
05
Acompanhe a taxa de acertos
Acompanhe com que frequência uma visualização é servida pelo cache. Uma taxa baixa significa que a chave é muito específica ou que os usuários abrem um novo domínio a cada visita. Qualquer uma dessas descobertas é útil ao planejar o orçamento.
Dados desatualizados são uma escolha de produto ou um bug?
Um número de links pode ter um mês de idade e ainda estar correto para o índice do qual veio. Se sua tela diz isso é a verdadeira questão. A maioria dos tickets de suporte sobre números antigos são problemas de rótulos. Rótulos geralmente os resolvem.
Dê a cada figura seu mês do índice. Mostre aos usuários. Uma vez que eles podem ver a data, o número deixa de parecer um feed quebrado, e essa pequena linha faz mais do que um TTL menor jamais poderia.
Quanto tempo é demais para um número de links?
Nosso índice é atualizado aproximadamente uma vez por mês, então um número armazenado no primeiro dia descreve o mesmo índice que um armazenado no último dia. Nada na resposta muda dentro do mês. O problema começa quando um usuário espera um link de ontem, e então a correção é um rótulo claro, conforme abordado em rótulos de pontuação.
As chamadas de visão geral gratuitas precisam de cache?
A ação de visão geral não custa créditos, então o cache aqui protege a velocidade, não o saldo. Seu servidor ainda paga por cada ida e volta, e uma página que abre cinquenta vezes por minuto vai sentir isso. Armazene também as respostas gratuitas, com a mesma chave mensal, e a página permanece rápida enquanto seu proxy permanece silencioso. As notas de consulta pública explicam a mesma ideia para visitantes.
Um link novo deve contornar o cache?
Geralmente não. Um contorno custa créditos por uma resposta que provavelmente é idêntica à armazenada. Se um cliente insistir, explique o mês do índice e ofereça uma atualização manual por workspace por mês, em vez de um botão aberto que qualquer um pode pressionar em loop.
Proteção contra stampede e outras pequenas coisas
Single-flight: se dez usuários abrirem o mesmo domínio, faça uma chamada upstream e compartilhe a promessa.
Aqueça no primeiro do mês com um job em segundo plano, não às 9h quando os usuários chegam.
Armazene a resposta _credits.remaining e alerte abaixo de um limite que você escolher.
Faça cache do resultado negativo 'domínio não encontrado' por um dia, não um mês.
Exponha a idade do cache na UI para que o suporte possa responder 'quando isso foi buscado?'
Por que um cache supera o scraping para verificações de links
Equipes que precisam verificar backlinks de páginas em escala geralmente começam com scripts que consultam mecanismos de busca diretamente. Esses scripts travam. Eles parecem baratos no primeiro dia, é por isso que as equipes os mantêm muito mais tempo do que deveriam. Um cache na frente de uma API estável é geralmente o design mais barato, com menos partes móveis para cuidar.
A diferença aparece em horas de engenharia mais do que na primeira fatura. Mantenha o cache simples, e a maioria dessas horas nunca acontece.
Por que verificadores de links caseiros continuam travando?
Os mecanismos de busca limitam consultas automatizadas, então um script que roda limpo para cinquenta URLs pode travar em cinquenta mil. Retries, pools de proxy e atrasos aleatórios adicionam custos que nunca aparecem em uma linha de créditos, e eles quebram sem aviso quando o alvo muda suas respostas.
Como manter um job de lista longa reiniciável?
Escreva cada domínio concluído no cache conforme avança. Se o job parar no meio do caminho, uma reinicialização pula todos os domínios que já têm uma resposta armazenada e retoma de onde parou. Nada é cobrado duas vezes pelo mesmo mês, porque a chave já contém a resposta.
Execute o job em um ritmo constante, não em um único burst. Espaçar as chamadas mantém os logs legíveis e torna qualquer mudança no uso de créditos fácil de explicar.
Quanto custa uma lista de 22.000 URLs com um cache?
Digamos que você precise verificar 22.000 URLs vinculantes para um cliente. Muitos deles compartilham um domínio, então dedupe para domínios primeiro. Esses 22.000 links podem ser reduzidos a algumas milhares de domínios únicos, e uma chamada bulk_dr leva até 2.000 deles por um único crédito. Armazene cada resultado por domínio e mês, e a lista deixa de ser um trabalho por URL. Mantenha a aritmética em uma nota curta ao lado do job, para que a próxima pessoa possa executá-lo novamente com um tamanho de lista diferente. Um número com seu cálculo mostrado é mais fácil de confiar do que um total sozinho.
Onde isso se conecta
O cache é a camada intermediária no configuração de contador. Uma vez que funciona, o custo por assento torna-se previsível e você pode precificar um plano em torno disso com a comparação por assento. Páginas curtas merecem um fim claro. Esta tem.
Perguntas sobre cache que vemos em code review
O cache deve viver no navegador também?
Um cache curto no navegador ajuda na navegação pelo botão voltar, mas o cache compartilhado no seu servidor faz a economia real. Mantenha o armazenamento do lado do cliente por minutos, já que usuários em máquinas diferentes veriam números diferentes para o mesmo domínio no mesmo dia.
E se um cliente disser que um novo link está faltando?
Verifique o mês do índice mostrado na sua UI. Se o link foi adicionado após a última atualização, ele aparecerá após a próxima. Ofereça uma nota, não um reembolso, porque nada está quebrado.
Posso contornar o cache sob demanda?
Você pode, mas cada contorno custa créditos por uma resposta que provavelmente é idêntica. Ofereça apenas para administradores e limite a taxa por workspace para evitar loops acidentais.
Paginação e a chave de cache
A paginação morda todos uma vez. Inclua-a na chave.
As ações backlinks e refdomains retornam até 1.000 linhas por chamada, com page e per entre 10 e 5000, e paginação profunda é limitada a 50.000 linhas, então uma chave sem esses parâmetros servirá a página um para todas as solicitações.
A ordenação pertence à chave também. Um usuário que inverte de DR descendente para alfabético espera uma lista diferente, e o cache deve obedecer sem uma nova chamada upstream quando o conjunto completo já está armazenado.
Um teste rápido captura a maioria dos erros de chave. Solicite a página dois, altere a ordenação, então verifique se a página dois armazenada difere da página um armazenada. Se não diferir, a chave está faltando um parâmetro. Encontrado cedo, custa minutos. Um cliente nunca vê. Execute o teste novamente antes de cada lançamento, porque uma nova opção de ordenação é o motivo usual pelo qual a chave quebra. Escreva-o na sua lista de verificação de lançamento.
Planeje o botão de exportação separadamente: um job em segundo plano, um arquivo armazenado e uma notificação quando estiver pronto.
