피드로 돌아가기
How Shopify's GraphQL Rate Limits Actually Work (and How to Stop Getting 429'd)
Dev.toDev.to
Backend

Query Cost 기반 Token Bucket 설계를 통한 429 에러 원천 차단

How Shopify's GraphQL Rate Limits Actually Work (and How to Stop Getting 429'd)

Muhammad Masad Ashraf2026년 6월 22일6intermediate

Context

기존 REST API의 단순 요청 횟수 제한 방식은 데이터 복잡도를 반영하지 못하는 한계 존재. Shopify GraphQL API는 정적 분석을 통한 Query Cost 모델을 도입하여 리소스 소모량에 따른 차등 제한 체계 적용.

Technical Solution

  • Static Analysis를 통한 실행 전 Query Cost 산출 및 Bucket 포인트 차감 구조 설계
  • Scalar(0pt), Object(1pt), Connection(2pt + N), Mutation(10pt)으로 세분화된 비용 산정 체계 구축
  • Client-side Token Bucket 구현을 통한 서버 요청 전 가용 포인트 사전 검증 및 대기 로직 적용
  • Redis 기반의 분산 락/카운터 공유를 통해 다중 Worker 환경에서의 Quota 동기화 달성
  • 1,000포인트 초과 대량 데이터 처리를 위해 Synchronous Query에서 Bulk Operations API로 전환하는 전략 채택
  • Exponential Backoff와 Jitter를 결합한 재시도 메커니즘으로 Thundering Herd 문제 방지

1. 응답 헤더의 throttleStatus를 파싱하여 로컬 Token Bucket 상태를 실시간 동기화할 것

2. 단일 쿼리 비용이 1,000pt를 초과하거나 데이터셋이 1,000건 이상일 경우 Bulk Operations API로 대체할 것

3. Webhook을 우선 적용하여 불필요한 Polling으로 인한 포인트 소모를 최소화할 것

4. Mutation 실패 시 HTTP 200 응답 내 userErrors 필드를 반드시 검증하여 비즈니스 로직 에러를 처리할 것

원문 읽기