donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
cfd84875bf9799a0d2d11d78d2a6201ea7e255f1
llm-wiki/raw/company-tech-blogs/outbound-stripe-rate-limit-retry-engineering.md
T

9.5 KiB
Raw Blame History

title, source_type, status, confidence, url, archive_url, related_branches, related_projects, tags, created, last_reviewed
title source_type status confidence url archive_url related_branches related_projects tags created last_reviewed
Stripe Engineering — rate limiting, idempotency retry, exponential backoff company-tech-blog raw high https://stripe.com/blog/rate-limiters
feature-outbound-http-client-baseline
feature-rate-limit-idempotency-contract
ca-tmpl
ca-outbound-http
stripe
rate-limit
retry
backoff
idempotency
circuit-breaker
2026-05-22 2026-05-27

Stripe Engineering — rate limiting, idempotency retry, exponential backoff

Layer: raw/company-tech-blogs/ — Stripe Engineering blog "Scaling your API with rate limiters" 의 4가지 rate limiter 분류 발췌. ca-tmpl outbound retry/timeout 결정의 사례 근거 (company-case-study). 공식 best practice 로 격상 금지.

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-outbound-http-client-baseline retry default-disabled vs default-enabled 의 비교 사례 (Stripe 는 SDK 측 enabled-by-default, ca-tmpl 은 conservative default-disabled — 비교 reference)
raw/branch-notes/feature-rate-limit-idempotency-contract idempotency-key + retry 결합의 산업 사례 + 4가지 rate limiter 분류의 부분 사례

컨텍스트

ca-tmpl outbound retry/timeout 결정의 사례 근거. Stripe 는 retry 정책과 idempotency 를 결합한 대표 사례 — 단, company-case-study 강도. 공식 best practice 로 격상 금지 (CLAUDE.md §5).

출처 / Source

  • Stripe Engineering blog "Scaling your API with rate limiters": https://stripe.com/blog/rate-limiters
  • 아카이브 URL: (미수집)
  • 저자 / 조직: Paul Tarjan (Stripe Engineering)
  • 발행일: 2017-08-31 (블로그 메타데이터 기준)
  • 마지막 확인일: 2026-05-27

핵심 인용 / Key quotes (verbatim)

[§Request rate limiter] "This rate limiter restricts each user to N requests per second."

[§Concurrent requests limiter] "Instead of 'You can use our API 1000 times a second', this rate limiter says 'You can only have 20 API requests in progress at the same time'."

[§Fleet usage load shedder] "We always reserve a fraction of our infrastructure for critical requests."

[§Worker utilization load shedder] "If a box is too busy to handle its request volume, it will slowly start shedding less-critical requests."

[§Intro paragraph (idempotency context)] "If you're providing an API, chances are you've already experienced sudden increases in traffic that affect the quality of your service, potentially even leading to a service outage for all your users."

Claims Extracted / 추출된 주장

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
STRIPE-RL-C1 Stripe 는 production 에서 request rate limiter 를 운용하며 사용자별 초당 N requests 제한 [§Request rate limiter] "This rate limiter restricts each user to N requests per second." company-case-study Stripe API gateway 의 inbound 제어 사례 모든 API 가 동일한 1차원 rate limiting 만 쓴다는 뜻 아님 — 본 blog 가 4종 병행 명시
STRIPE-RL-C2 Stripe 는 concurrent requests limiter 도 운용 — "동시 진행 중인 API request 수" 를 사용자별로 제한 (예: 20 in progress) [§Concurrent requests limiter] "Instead of 'You can use our API 1000 times a second', this rate limiter says 'You can only have 20 API requests in progress at the same time'." company-case-study 장시간 outbound 호출 (large LIST 등) 의 amplification 차단 사례 "20" 이 universal default 라는 뜻 아님 — Stripe 내부 운영 수치
STRIPE-RL-C3 Stripe 는 fleet usage load shedder 로 critical request 용 infrastructure fraction 을 항상 예약 [§Fleet usage load shedder] "We always reserve a fraction of our infrastructure for critical requests." company-case-study critical/non-critical traffic 분리 운영 사례 "어떤 비율로 예약" 또는 "어떻게 critical 을 구분" 의 정확한 메커니즘은 본 인용에 없음
STRIPE-RL-C4 Stripe 는 worker utilization load shedder 로 box 가 과부하 시 less-critical request 부터 점진적으로 shed [§Worker utilization load shedder] "If a box is too busy to handle its request volume, it will slowly start shedding less-critical requests." company-case-study per-instance overload 대응 사례 "less-critical" 의 자동 분류 메커니즘은 본 인용에 없음 — 별도 출처 (Stripe API ref 의 priority tier) 필요
STRIPE-RL-C5 이전 메모의 "Stripe SDK 가 409/429/500/502/503/504 + idempotency-key 자동 + full jitter 0.5x~1.5x + 2-3 attempts" 주장은 본 WebFetch (rate-limiters blog) 에서 확인 안 됨 — Stripe API reference 의 별도 페이지 또는 stripe-java SDK 코드에서 검증 필요 (negative finding — rate-limiters blog 에 retry attempt 수치 / Idempotency-Key 헤더 / backoff 산식 명시 없음) needs-confirmation retry 정책 / idempotency-key 자동 첨부 / backoff jitter 의 정확한 정책 인용 시 이 부정 확인은 Stripe SDK 가 그렇게 동작하지 않는다 는 뜻이 아니라, 본 blog 만으로는 증명 안 됨 — 별도 출처 (https://stripe.com/docs/api 의 Retries 절, stripe-java repo 의 StripeResponseGetter) 필요

Usage Boundaries / 적용 경계

  • 이 자료가 직접 증명하는 것:
    • STRIPE-RL-C1 ~ C4: Stripe production 의 4종 rate limiter 분류 (request / concurrent / fleet usage / worker utilization) — Stripe 사례 한정
  • 이 자료가 증명하지 않는 것:
    • "Stripe's SDKs automatically retry network errors and certain HTTP status codes (409, 429, 500, 502, 503, 504) with exponential backoff" 의 정확한 문구 — 본 blog 에 없음 (STRIPE-RL-C5). Stripe API reference Retries 절 별도 확인 필요
    • "Idempotency-Key header automatically generated by the SDK" — 본 blog 에 없음. stripe-java repo 코드 별도 확인 필요
    • "retry interval is randomized between 0.5 and 1.5 times the baseline (full jitter)" — 본 blog 에 없음. backoff 산식 별도 출처 필요
    • "Retries are bounded: 2-3 attempts" — 본 blog 에 없음. SDK 코드 별도 확인 필요
    • 4종 rate limiter 의 정확한 구현 (token bucket / sliding window / semaphore 등) — 본 인용 범위 밖
    • 공식 best practice 로 격상 금지 (CLAUDE.md §5) — company-case-study 강도. 산업 표준이라고 말하려면 IETF draft / RFC / 다른 official-vendor-doc 와 corroborate 필요
  • 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
    • ca-tmpl 의 "retry default-disabled" 결정 정당화는 본 blog 로는 반례 (Stripe enabled-by-default) 만 확인됨. Stripe 의 default-enabled 가 가능한 이유 (idempotency-key 자동 첨부 가정) 는 needs-confirmation
    • 429 Retry-After header honor 정책 — 본 blog 에 없음. Resilience4j default 동작 별도 확인 + Stripe 정책 별도 출처 필요
    • 4종 rate limiter 가 ca-tmpl inbound 측에 적용될 수 있는지는 outbound baseline 결정과 직교

메모 / Notes (내 프로젝트 해석)

본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

  • ca-tmpl 결정과의 매핑 (해석):
    • "retry 기본값 disabled" ↔ Stripe SDK 는 enabled-by-default (해석, STRIPE-RL-C5 needs-confirmation). 반례. ca-tmpl 이 보수적인 이유: provider 별 retry 정책이 다른 mixed 환경에서 default-on 은 amplification 위험.
    • "idempotent method (GET/HEAD/PUT/DELETE) 만 default retry" ↔ Stripe 는 POST 도 idempotency-key 가 있으면 retry (해석, needs-confirmation). ca-tmpl 과 같은 원칙 (key 없는 POST 는 retry 금지).
    • "circuit breaker metric outcome tag 만" ↔ Stripe blog 의 "load shedder" 4종 분류 (STRIPE-RL-C1 ~ C4) 와 동일한 사상: 상태를 단순 fail/success 이상으로 분리 (해석).
  • backoff 정책 (해석, STRIPE-RL-C5 needs-confirmation):
    • Stripe: full jitter random(0.5x, 1.5x baseline) (별도 출처 필요). ca-tmpl 이 Resilience4j 도입 시 IntervalFunction.ofExponentialRandomBackoff 활용 가능.
  • retry-after header 처리 (해석, needs-confirmation):
    • Stripe 429 → Retry-After 헤더 honor. ca-tmpl outbound 매핑에서도 429 를 retryable 로 분류 시 retry-after 를 read 해야 함 (Resilience4j Retry 는 default 로 안 함, 커스텀 필요).
  • 취급 주의 (CLAUDE.md §5 + §11):
    • Stripe 엔지니어링 블로그는 사례. "Stripe 가 그러니까 best-practice" 는 금지.
    • idempotency-key + retry 결합은 IETF draft / Stripe API ref / Square API 에서 동일하게 권장 → 사실상 산업 표준 (해석 — 본 raw 만으로는 corroboration 미달, UNSUPPORTED_DECISION 으로 분류).
  • 시사점: ca-tmpl 이 default-disabled 를 택한 것은 provider 별 정책 차이를 인지한 conservative default. Stripe 처럼 idempotency 가 보장된 환경에서는 활성화 권장 (해석).

Related / 관련

Reference in New Issue View Git Blame Copy Permalink