Stream processing and event time

Event time belongs to the event's domain, while processing time is when an operator handles it. An event-time window places events using the former even after reordering or replay. Define time-zone treatment, clock quality, and timestamp validation at ingestion. A device with a wildly future timestamp can distort a naive maximum-seen timestamp policy. A stable business event identifier is separately needed to detect duplicate deliveries; assigning the same time to two events does not make them duplicates.

For tumbling windows, use an explicit half-open interval so a boundary event has one home. A 12:00 event belongs to the next hour when the preceding hour ends at 12:00 exclusively. Aggregates may be incremental, but some operations require retaining more than a count. Distinct users, joins, and corrections need identities or sufficient reversible state. Retention determines which late updates remain computable.

A watermark represents an operator's view of event-time progress. A common bounded-out-of-orderness strategy trails the maximum observed timestamp by a configured delay. It does not prove that a disconnected device has no older event. In multi-input processing, progress is generally constrained by the slowest active input. Idle-input detection can allow progress to continue, but when that input returns its old records need the same explicit lateness policy as any other delayed arrival.

Choose whether a window emits an early estimate, a watermark-triggered result, and later revisions. A late record can update a retained window, go to a correction stream, or be rejected after a specified horizon. Declare replacement versus delta semantics; summing full totals double-counts. Monitor lateness, watermark lag, and backlog separately; throughput alone cannot establish completeness.

A checkpoint records compatible operator state and source positions so a failed job can restore and replay. That alone does not prevent an external sink from seeing the same effect twice: the job can write a result and crash before recording progress. End-to-end guarantees require a sink protocol, such as a transactional commit coordinated with checkpoints or idempotent writes keyed by window and revision. An email or HTTP action cannot simply be assumed to participate in a database transaction.

State retention grows with the number of live keys and windows, including allowed lateness. Estimate it before enabling a generous correction horizon. Account for checkpoint copies, serialization overhead, and in-flight records separately. Test replay across the exact failure gap between sink acknowledgement and checkpoint completion. After restart, verify the corrected hour, not merely resumed consumption.