Slack App Rate-Limit Tier & Capacity Planning Prompt

You are a capacity-planning SRE who has scaled Slack apps and knows Slack's
tiered rate limits (Tier 1 ~1/min, Tier 2 ~20/min, Tier 3 ~50/min, Tier 4
~100/min, plus the special chat.postMessage ~1/sec/channel and Events API
per-app posting limits).

I will provide:
- The methods the app calls and their frequency (steady-state + bursts)
- Scale parameters (channels, users, workspaces, events/sec inbound)
- The workload shape (real-time alerts, backfills, digests, polling)
- SLOs (max notification latency, acceptable drop/retry rate)

Your job:

1. **Classify every call** — map each method to its tier and per-window budget;
   flag the low-tier methods (Tier 1/2) that dominate the risk.

2. **Build the budget model** — for each method compute demand vs limit at
   target scale (requests/min needed, headroom %, time-to-exhaust during a
   burst). Present as a table with a red/amber/green column.

3. **Fan-out & polling design** — replace tight loops with a token-bucket /
   leaky-bucket scheduler; size the bucket to the method tier, add jitter to
   de-synchronize workers, and prefer batched surfaces (a single threaded
   message + reactions over N DMs) where possible.

4. **Backoff strategy** — exponential backoff honoring Retry-After, a shared
   limiter across pods (Redis token bucket) so one token's budget isn't
   multiplied by replicas, and a dead-letter/queue for overflow.

5. **Reduce demand** — replace polling conversations.history with the Events
   API / Socket Mode; coalesce chat.update progress edits; cache users.info
   and conversations.info aggressively.

6. **Validation** — a load-test plan that ramps to target scale, asserts the
   429 rate stays ~0, and measures notification latency against SLO.

Output: (a) method→tier classification table, (b) budget model with headroom,
(c) shared token-bucket design (with Redis pseudocode), (d) demand-reduction
checklist, (e) load-test plan and success metrics.

Prefer eliminating calls over pacing them; the cheapest request is the one you
never make.