Choose between Inngest throttle, rateLimit, debounce and concurrency for flow control

Documented steps

1. Decide first whether excess work must be preserved or may be discarded — that single question separates throttle from rateLimit.
2. Use `throttle: { limit, period, burst?, key? }` when every event must eventually run but starts must be paced. Excess runs are ENQUEUED (GCRA, FIFO) and start later. `period` accepts 1 second to 7 days. Ref: https://www.inngest.com/docs/guides/throttling
3. Use `rateLimit: { limit, period, key? }` when excess work should be DROPPED — events over the limit are skipped and never trigger a run (the raw events are still stored and visible). Documented `period` range on the reference page is 1s to 60s. Ref: https://www.inngest.com/docs/guides/rate-limiting
4. Use `debounce: { period, key?, timeout? }` to collapse a burst of updates into one run using the LAST event received; the period restarts on each new matching event. `period` is 1s to 7d; set `timeout` to guarantee execution under a continuous stream. Ref: https://www.inngest.com/docs/guides/debounce
5. Use `concurrency` to cap simultaneous execution rather than start rate — see the dedicated concurrency route.
6. Use `singleton: { key?, mode: "skip" | "cancel" }` when only one run per key may exist at a time (SDK v3.39.0+/Go v0.12.0+/Python v0.5+). Ref: https://www.inngest.com/docs/guides/singleton
7. Use `priority: { run: "<CEL expression returning seconds>" }` to reorder an existing queue; the value is bounded to -600..600 seconds and only matters when a queue actually forms. Ref: https://www.inngest.com/docs/guides/priority
8. Combine deliberately: concurrency + throttle is the common pairing for a rate-limited upstream with per-tenant fairness.