Event Time vs Processing Time
The distinction between when something happened in the world and when the system got round to handling it.
Processing time is the clock on the machine doing the work. Event time is the timestamp on the event itself. They are never equal, and the gap is variable, unbounded and largest exactly when things are going wrong.
Almost every correctness question in streaming reduces to which of these a computation uses. Aggregating by processing time is trivial to implement and produces results that are not reproducible — replay the same data through the same code and the windows fall differently, because the timings differ. Aggregating by event time is reproducible, matches what the business means by "sales in the 09:00 hour", and requires watermarks, buffering and a late-data policy.
The practical rule: anything reported to the business, reconciled against another system, or used to compute a metric with a legal or financial meaning must use event time. Operational monitoring of the pipeline itself is legitimately processing time — you want to know throughput now, not throughput attributed to when the events were created.
The failure that exposes a processing-time design is a consumer outage. When the backlog drains, four hours of events all arrive within ten minutes, and a processing-time aggregation records a massive spike that never occurred.