레시피

API를 통해 페이지 백링크를 확인하고 정직하게 캐싱하기

당사의 인덱스는 월 단위로 업데이트되므로 대부분의 조회는 메모리에서 처리할 수 있습니다. 크레딧을 절약하면서도 사용자에게 낡은 데이터를 보여주지 않는 캐싱 레시피입니다.

AlfaLinks 편집팀 · 업데이트 2026-10-29

캐시된 백링크 데이터의 신선도를 나타내는 색색의 모래가 담긴 세 개의 항아리가 있는 돌다리

규칙

고정된 시간 대신 다음 인덱스 갱신까지 캐싱하기

데이터가 대략 월 단위로 변경되므로, 시간 단위 TTL은 비용만 증가시킬 뿐입니다. 월 단위의 키는 한 달 내내 동일한 결과를 제공하며 한 번의 작업으로 무효화됩니다.

키: 작업 + 도메인 + 파라미터 + 인덱스 월
TTL: 월 말까지, plus 관용 기간 하루 추가
오류 응답은 절대 캐싱하지 마세요

짧은 TTL이 크레딧 잔액에 대한 단순한 기부금인 이유

링크 데이터에 익숙하지 않은 팀은 랭크 트래커의 습관을 그대로 복사합니다. 첫 번째 습관: 순위가 자주 변하므로 시간 단위 캐싱. 링크 그래프는 거의 변하지 않습니다.

2 크레딧이 소모되는 backlinks 호출 비용은 $0.0002입니다. 이는 작은 금액처럼 보이지만, 페이지 로드 시 400개의 활성 워크스페이스에서 각 페이지당 50번의 호출이 발생하고 매시간 동일한 결과를 위해 반복되면 이야기가 달라집니다.

아래의 계산 예시는 실제 트래픽을 측정한 것이 아닙니다. 400개의 워크스페이스, 하루에 도메인 뷰 20회, 뷰당 2 크레딧, 그리고 1시간 캐싱 히트율이 5분의 1에 불과하다고 가정합니다. 대부분의 뷰는 여전히 API에 접근합니다. 월 단위 키를 사용하면 동일한 트래픽이 도메인당 월 1회만 API에 접근하므로, 이 차이가 레시피의 핵심입니다.

키워드 리서치 도구는 더 신선한 데이터가 필요하므로, 이러한 경우 대형 스위트가 여전히 더 나은 선택입니다. 링크 컨텍스트의 경우 월 단위가 제품입니다.

작업별 TTL

제안 사항일 뿐 강제 사항은 아닙니다. 모든 작업은 동일한 월 인덱스를 읽습니다.
작업	크레딧	제안 TTL	이유
개요, 통계	0	월 말까지	무료이지만 서버의 지연 시간도 절약됩니다
bulk_dr	1	월 말까지	한 번의 호출로 전체 고객 테이블 처리
refdomains, backlinks	2	페이지 파라미터별 월 말까지	페이지, per, sort를 키에 포함하세요
anchors, toppages	2	월 말까지	갱신 간 안정적
search, keyword	3	7일	반복 호출이 드물며 캐싱을 생략하는 것이 저렴함

요청 예시: 고객 테이블을 위해 캐시 워밍업하기

행 단위 대신 고객별로 bulk_dr 호출을 한 번만 수행하세요. POST 본문에는 최대 2,000개의 도메인을 포함할 수 있으며 비용은 1 크레딧입니다.

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

5단계로 캐시 구축하기

각 단계에는 하나의 역할이 있습니다. 하나를 건너뛰면 나중에 실패가 나타나며, 보통 청구서 형태로 나타납니다.

키 선택하기

작업, 도메인, 페이지네이션 및 정렬 파라미터, 인덱스 월을 사용하세요. 표시 색상이나 탭 이름처럼 결과를 변경하지 않고 사용자가 변경할 수 있는 요소는 제외하세요.

파싱된 응답 저장하기

원시 바이트가 아닌 ok 플래그와 데이터가 포함된 디코딩된 JSON을 보관하세요. 이후 뷰는 두 번째 호출 없이 메모리에서 전체 테이블을 다시 구성할 수 있습니다.

월 말에 만료되도록 설정하기

만료 시간을 인덱스 월의 마지막 날과 위의 규칙에 따른 관용 기간 하루로 설정하세요. 모든 작업에 동일한 규칙을 적용하여 로직을 다섯 곳에 분산하지 않고 하나의 함수로 관리하세요.

모든 호출 시 잔액을 로깅하기

인증된 응답의 _credits 객체를 읽고 나머지 잔액을 자체 로그에 기록하세요. 해당 줄의 점진적인 감소는 종종 캐시 키가 잘못되었음을 나타내는 첫 번째 징후입니다.

히트율 모니터링하기

뷰가 캐시에서 제공되는 빈도를 추적하세요. 낮은 히트율은 키가 너무 구체적이거나 사용자가 매번 새로운 도메인을 조회한다는 의미입니다. 이러한 발견은 예산 계획 시 유용합니다.

낡은 데이터는 제품 선택인가, 버그인가?

링크 수치는 한 달 전일 수 있지만 해당 인덱스에서는 여전히 정확할 수 있습니다. 화면에 그렇게 표시되는지가 실제 질문입니다. 오래된 수치에 대한 지원 문의의 대부분은 라벨링 문제입니다. 라벨로 대부분 해결됩니다.

각 수치에 인덱스 월을 표시하세요. 사용자에게 보여주세요. 날짜를 볼 수 있게 되면 그 수치는 깨진 피드처럼 보이지 않으며, 이 작은 라벨은 짧은 TTL보다 훨씬 더 많은 역할을 합니다.

링크 수치에 있어 너무 오래된 기준은 무엇인가?

당사의 인덱스는 대략 월 단위로 갱신되므로, 첫날에 캐싱된 수치는 마지막 날에 캐싱된 수치와 동일한 인덱스를 설명합니다. 한 달 동안 답변의 내용은 변경되지 않습니다. 문제는 사용자가 어제의 링크를 기대할 때 발생하며, 이때 해결책은 스코어 라벨에서 다루는 명확한 라벨입니다.

무료 개요 호출에도 캐시가 필요한가?

개요 작업은 크레딧이 소모되지 않으므로, 여기서 캐시는 잔액보다 속도를 보호합니다. 서버는 라운드 트립마다 비용을 지불하며, 분당 50회 열리면 페이지가 느려질 수 있습니다. 무료 답변도 동일한 월 키로 저장하면 페이지는 빠르고 프록시는 조용하게 유지됩니다. 공개 조회 참고 사항은 방문자에게 동일한 아이디어를 설명합니다.

신선한 링크가 캐시를 우회해야 하는가?

보통 아닙니다. 우회는 아마도 캐시된 결과와 동일할 답변에 대해 크레딧을 소모합니다. 고객이 고집한다면 인덱스 월을 설명하고, 누구나 반복해서 누를 수 있는 열린 버튼 대신 워크스페이스당 월 1회 수동 새로 고침을 제안하세요.

스탬페디 보호 및 기타 작은 사항들

싱글 플라이트: 10명의 사용자가 같은 도메인을 열면 하나의 업스트림 호출을 수행하고 결과를 공유하세요.
사용자가 도착하는 오전 9시가 아닌 월 1일 배경 작업으로 워밍업하세요.
응답의 _credits.remaining을 저장하고 선택한 임계값 아래로 떨어지면 알림을 보내세요.
'도메인 없음'이라는 음수 결과는 한 달이 아닌 하루 동안 캐싱하세요.
지원팀이 '언제 가져왔나요?'에 답변할 수 있도록 UI에 캐시 연령을 노출하세요.

링크 확인을 위해 스크래핑보다 캐시가 나은 이유

대규모로 페이지 백링크를 확인해야 하는 팀은 종종 검색 엔진에 직접 쿼리하는 스크립트로 시작합니다. 이러한 스크립트는 중단됩니다. 첫날에는 저렴해 보이므로 팀이 필요 이상으로 오래 유지합니다. 안정적인 API 앞의 캐시는 일반적으로 더 저렴한 설계이며 관리해야 할 요소가 적습니다.

차이는 첫 번째 청구서보다 엔지니어링 시간에서 나타납니다. 캐시를 지루하게 유지하면 이러한 시간의 대부분은 발생하지 않습니다.

자체 제작 링크 체크기는 왜 계속 중단되는가?

검색 엔진은 자동화된 쿼리를 제한하므로, 50개의 URL에서 잘 작동하던 스크립트가 50,000개에서 중단될 수 있습니다. 재시도, 프록시 풀 및 무작위 지연은 크레딧 라인에 표시되지 않는 비용을 추가하며, 대상의 응답이 변경되면 경고 없이 중단됩니다.

긴 목록 작업을 재시작 가능하게 유지하는 방법은?

완료된 도메인을 진행하면서 캐시에 기록하세요. 작업이 중간에 중단되면 재시작 시 이미 저장된 답변이 있는 도메인은 건너뛰고 중단된 지점부터 다시 시작합니다. 키에 이미 답변이 포함되어 있으므로 한 달 동안 동일한 도메인에 대해 두 번 청구되지 않습니다.

한 번에 몰아서가 아닌 일정한 속도로 작업을 실행하세요. 호출 간격을 두면 로그가 읽기 쉬워지고 크레딧 사용량의 변경 사항을 쉽게 설명할 수 있습니다.

캐시를 사용할 때 22,000개 URL 목록의 비용은?

한 클라이언트를 위해 22,000개의 링크 URL을 확인해야 한다고 가정해 보세요. 많은 URL이 도메인을 공유하므로 먼저 도메인으로 중복 제거하세요. 22,000개의 링크는 몇 천 개의 고유 도메인으로 줄어들 수 있으며, bulk_dr 호출은 최대 2,000개를 한 번의 크레딧으로 처리합니다. 결과를 도메인 및 월별로 저장하면 목록이 URL별 작업이 아닙니다. 작업 옆에 짧은 계산 메모를 유지하여 다음 사람이 다른 목록 크기로 다시 실행할 수 있게 하세요. 계산 과정이 표시된 숫자는 단독 총액보다 신뢰하기 쉽습니다.

연결 위치

캐시는 카운터 설정의 중간 계층입니다. 작동하면 좌당 비용이 예측 가능해지며 좌당 비교를 통해 이를 기반으로 요금제를 가격 책정할 수 있습니다. 짧은 페이지는 명확한 종료가 필요합니다. 이 페이지에도 있습니다.

코드 리뷰에서 자주 묻는 캐시 질문

캐시를 브라우저에도 두어야 하는가?

짧은 브라우저 캐시는 뒤로가기 탐색에 도움이 되지만, 서버의 공유 캐시가 실제 절감을 제공합니다. 클라이언트 측 저장소는 분 단위로 유지하세요. 그렇지 않으면 다른 기기의 사용자가 같은 날 같은 도메인에 대해 다른 수치를 보게 됩니다.

고객이 새로운 링크가 누락되었다고 말하면?

UI에 표시된 인덱스 월을 확인하세요. 링크가 마지막 갱신 이후에 추가된 경우 다음 갱신 후에 나타납니다. 오류가 없으므로 환불이 아닌 메모를 제공하세요.

요청 시 캐시를 우회할 수 있는가?

가능하지만, 각 우회는 아마도 동일한 답변에 대해 크레딧을 소모합니다. 관리자에게만 제공하고 우발적인 루프를 피하기 위해 워크스페이스당 속도 제한을 적용하세요.

페이지네이션과 캐시 키

페이지네이션은 모두를 한 번 괴롭힙니다. 키에 포함하세요.

backlinks 및 refdomains 작업은 호출당 최대 1,000개의 행을 반환하며, page 및 per는 10에서 5000 사이이며 깊은 페이지네이션은 50,000행으로 제한됩니다. 따라서 이러한 파라미터가 없는 키는 모든 요청에 대해 페이지 1을 제공합니다.

정렬도 키에 포함되어야 합니다. 사용자가 DR 내림차순에서 알파벳순으로 변경하면 다른 목록을 기대하며, 전체 세트가 이미 저장된 경우 새 업스트림 호출 없이 캐시가 이에 부응해야 합니다.

빠른 테스트로 대부분의 키 실수를 잡을 수 있습니다. 페이지 2를 요청한 후 정렬을 변경하고 캐시된 페이지 2가 캐시된 페이지 1과 다른지 확인하세요. 다르지 않다면 키에 파라미터가 누락된 것입니다. 초기에 발견되면 분 단위의 비용이 듭니다. 고객이 보지 못합니다. 새로운 정렬 옵션이 키를 깨뜨리는 일반적인 이유이므로 각 릴리스 전에 테스트를 다시 실행하세요. 릴리스 체크리스트에 작성하세요.

내보내기 버튼은 별도로 계획하세요: 하나의 백그라운드 작업, 하나의 저장된 파일, 준비 완료 시 알림 하나.