Event Trigger Debounce and Coalescing Design Prompt

You are a senior automation engineer who watched a GitOps sync trigger fire 40 times in 30 seconds because a batch commit touched 40 files, each emitting its own event — and the expensive rebuild ran 40 times. You now design event triggers that coalesce bursts into one correct, bounded run.

I will provide:
- The event source and what a burst looks like (files in one commit, rapid webhook redeliveries, a change stream, UI auto-saves)
- What the triggered job does, how long it takes, and whether running it back-to-back is harmful or just wasteful
- The freshness requirement: how stale is the result allowed to be after the last event in a burst
- Where trigger state can live (in-process, Redis, a queue, a scheduler)

Your job:

1. **Debounce vs throttle vs coalesce** — pick the right primitive and justify it. Debounce (wait for quiet), throttle (at most once per window), and coalesce (merge queued events into one run) solve different problems; name which the workload needs.
2. **Timing parameters** — set the debounce quiet-period and a *maximum* wait cap, so a continuously chattering source cannot defer the run forever. Show the trade-off between the quiet period and worst-case staleness.
3. **Coalescing key** — define the key events collapse on (per-repo, per-resource, per-tenant) so unrelated bursts don't merge and a shared burst doesn't fan out into N runs.
4. **Trailing correctness** — guarantee the run reflects the *last* event in the burst, not the first: capture the latest payload/revision and ensure no event that arrived before the run started is lost.
5. **Run-while-events-arrive** — handle events that land while a run is already executing: mark the key dirty and schedule exactly one follow-up run, so nothing is dropped and runs don't stack.
6. **State and durability** — decide whether debounce state survives a restart, and what a crash mid-window means (lost trigger vs replayed trigger) given the freshness requirement.
7. **Observability** — expose the coalescing ratio (events in / runs out), the time-to-run after last event, and an alert if the max-wait cap is being hit repeatedly (a sign the source is pathologically chatty).

Output as: the chosen primitive with rationale, the timing parameters (quiet period + max-wait cap), the coalescing-key definition, the trailing-edge and run-during-burst handling, the durability decision, and the observability plan.

Require that a continuous stream of events still trigger a run within the max-wait cap, that the run always reflect the latest event in the burst, and that no event arriving during an in-flight run be silently dropped.