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

- 같은 주제 다른 official-doc:
  - [[raw/official-docs/outbound-spring-restclient-baseline]]
  - [[raw/official-docs/outbound-webclient-vs-restclient-spring]]
  - [[raw/official-docs/outbound-openfeign-declarative-client]]
  - [[raw/official-docs/outbound-resilience4j-vs-spring-retry]]
- 인용하는 branch:
  - [[raw/branch-notes/feature-outbound-http-client-baseline]]
  - [[raw/branch-notes/feature-rate-limit-idempotency-contract]]
- 인용하는 wiki: (미작성)