Event-Driven Fan-In Aggregation Window Design Prompt

You are a senior automation engineer designing the fan-in stage of an event pipeline: thousands of small events (per-resource alerts, per-file uploads, per-shard completions) must be aggregated into batches before a single downstream action fires — one bulk remediation, one summary notification, one rollup write. Done wrong, this stage either fires too early (incomplete batches), fires forever (windows that never close), or double-fires (a flushed window re-emitting).

I will provide:
- What the individual events are, their key (what they group by), and their arrival rate and burstiness
- What the aggregated action does and whether firing on an incomplete set is harmful or merely suboptimal
- The transport (Kafka, SQS, a webhook receiver, a stream processor) and its ordering/at-least-once guarantees
- How late, duplicate, and out-of-order events can occur, and any deadline by which the aggregate must fire

Your job:

1. **Window type** — choose tumbling, sliding, or session windowing from the grouping semantics I described, and justify it: fixed rollups want tumbling, "quiet for N seconds" wants session, overlapping trends want sliding.
2. **Close trigger** — define exactly what closes a window: a wall-clock timer, a count threshold, an end-of-batch sentinel event, or a watermark — and what happens when two triggers race.
3. **Watermarks and late events** — design a watermark so the window closes on event-time progress, not just wall clock, and specify the allowed-lateness grace period and where late events go (fold into a correction, drop, or route to a side output).
4. **State and keys** — specify where per-window partial state lives, how it is keyed, its memory/size bounds, and how a window is evicted so a never-completing key cannot leak state forever.
5. **Idempotent flush** — design the flush so a window emits its aggregate exactly once even under at-least-once redelivery and consumer restarts; include the dedupe/commit ordering (emit-then-commit vs commit-then-emit) and its failure implications.
6. **Incomplete-window policy** — decide what happens when a window's deadline passes with only part of the expected events: fire partial with a completeness flag, fire and reconcile later, or alert — matched to whether partial firing is harmful.
7. **Backpressure and observability** — handle bursts without unbounded buffering, and define metrics for open windows, window age, late-event rate, and flush duplicates, with an alert for "windows not closing."

Output as: the window-type choice, the close-trigger rules, the watermark/lateness design, the keyed-state model with eviction, the idempotent-flush protocol, the incomplete-window policy, and the observability plan.

Require that every window provably closes (by watermark, timeout, or count) so no key leaks state forever, that flush be idempotent under redelivery and restart, and that firing on an incomplete window be an explicit, flagged decision rather than an accident of timing.