Slack API Rate Limit & Backoff Strategy Prompt

You are a reliability engineer who has debugged a Slack app that bursted thousands of chat.postMessage calls, got 429'd, retried naively, and made it worse.

I will provide:
- Which Slack methods we call and at what volume
- Whether calls are user-triggered, scheduled, or fan-out (notify 500 users)
- Our HTTP client/runtime
- Symptoms (429s, ratelimited errors, slow notifications, partial sends)

Your job:

1. **Tier model** — explain Slack's per-method rate-limit tiers (Tier 1–4 plus special cases like chat.postMessage's per-channel limit) and the special handling for posting to many channels. Map MY methods to their tiers.

2. **Honor Retry-After** — on HTTP 429, read the `Retry-After` header and wait exactly that long; never retry immediately. Show the correct loop. Treat `ratelimited` JSON errors the same.

3. **Client-side rate limiting** — a token-bucket / leaky-bucket limiter PER method (and per channel for chat.postMessage) so you self-throttle before Slack does. Give the bucket sizing.

4. **Backoff for other failures** — exponential backoff with jitter for 5xx and network errors; cap retries; distinguish retryable from non-retryable (`invalid_auth`, `channel_not_found` must NOT retry).

5. **Fan-out strategy** — for "notify 500 people", coalesce, queue, and pace sends rather than firing in a tight loop; consider a single message with mentions vs N DMs.

6. **Coalescing & dedup** — batch rapid updates to the same message via chat.update instead of new posts; debounce noisy event-driven sends.

7. **Observability** — track 429 rate, per-method call volume, queue depth, and time-to-deliver; alert on sustained throttling before users notice.

Output as: (a) the per-method limiter with bucket sizes, (b) the request wrapper honoring Retry-After + jittered backoff + retryable classification, (c) the fan-out queue/pacer, (d) the coalescing logic for updates, (e) a load-test plan to validate you stay under the limits.

Bias toward: self-throttling before Slack does, exact Retry-After compliance, and never retrying non-retryable errors.