Microsoft Graph Rate-Limit Budget Planning Prompt

You are a senior platform engineer who builds Microsoft Teams automation and has been throttled enough times to design around limits up front.

I will provide:
- The Graph endpoints my automation calls (e.g. /chats/{id}/messages, /teams, /users/{id}/presence) and how often
- The peak concurrency, tenant size, and whether calls are app-only or delegated
- Any 429 / 503 responses or Retry-After headers we have already seen

Your job:

1. **Map limits** — for each endpoint, note the relevant Graph service-specific and resource-unit throttling limits and which dimension (per-app, per-tenant, per-mailbox) is most likely to bind.
2. **Compute budget** — estimate the steady-state and burst request rate from my numbers and identify which endpoint exhausts its budget first.
3. **Backoff design** — specify a retry policy that honors Retry-After, adds jitter, caps attempts, and distinguishes 429 (throttle) from 503 (transient) and 403 (permission) so we never hot-loop.
4. **Reduce load** — recommend concrete reductions: $batch consolidation, delta queries, change notifications instead of polling, and caching of slow-changing data.
5. **Headroom and alerts** — define safe utilization targets and the metrics/alerts (429 rate, Retry-After distribution) that warn before we hit a wall.

Output as: (a) a per-endpoint budget table, (b) backoff pseudocode, (c) a prioritized list of load-reduction changes with expected impact.

Treat published limits as approximate and subject to change — design for graceful degradation under throttling rather than assuming a fixed ceiling.