Stripe 429 Too Many Requests: backoff properly instead of hammering

# Stripe 429 Too Many Requests: backoff properly instead of hammering

## The symptom

HTTP `429` responses from the Stripe API, SDK raising rate-limit errors. Usually appears as a burst: a deploy, a backfill script, or a webhook handler that calls the API per event.

## Confirm the cause

Stripe measures rate limits in requests per second per account, with extra per-endpoint limits on some operations. A 429 means you exceeded them. Find the hot path: check which code path spiked (list calls in a loop, N+1 API calls in a webhook handler, a migration script with no throttle).

## The fix

**Immediate:** back off with exponential delay and jitter. Respect any `Retry-After` header. Never retry a 429 immediately in a tight loop; that is how a brief spike becomes a sustained outage.

**SDK knobs:** the official SDKs retry automatically with `maxNetworkRetries` (default 2 in most SDKs). For batch jobs, raise it and add your own throttle between calls. For webhook handlers, do the minimum work synchronously (verify, enqueue, return 200) and move Stripe API calls to a background worker.

**Structural:** the most common fix is not better retries but fewer calls:
- Expand nested objects (`expand: ['customer']`) instead of fetching them separately.
- Cache prices, products, and coupons; they barely change.
- Use webhooks to maintain local state instead of polling `list` endpoints.
- For data migrations, throttle to a fixed requests-per-second budget well under the limit.

## Verify the fix

Re-run the offending job against test mode and confirm zero 429s in the logs. Load-test the webhook handler at 2x expected peak event rate and confirm p99 latency stays flat. Set an alert on 429 rate so the next spike pages someone before customers notice.