Software Engineering Glossary

Event Time

Also known as: Event-Time Processing Event Timestamp

Event time is the timestamp of when an event actually happened on the producing device or service, stored on the record itself. Stream processing jobs that window on event time group records by that timestamp, so a late or replayed event still lands in the correct minute or session. This is the opposite of processing time, which is the wall clock on the machine that happens to see the record. Watermarks track how far event time has advanced so windows can close without waiting forever.

Key Takeaways

  • Event time lives on the record. Processing time lives on the worker. Only event time stays stable when you replay a Kafka topic.
  • A watermark is a guess that no more events older than time T will arrive. It is how windows close. It is not Kafka’s high watermark.
  • Late events still happen after the watermark. You drop them, send them to a side output, or allow lateness so the window can update a bit longer.
  • Stamp the timestamp as close to the source as you can. Stamping now() at ingest is processing time with extra steps.

How It Works

  1. Each record carries a timestamp such as occurred_at from the client, sensor, or originating service.
  2. The processor extracts that field and assigns it as the record’s event time.
  3. Watermarks flow with the stream and announce that event time has reached T.
  4. Operators close windows that ended at or before T and emit results, then apply the late-data policy to stragglers.

Where It Is Used

  • Apache Flink and Kafka Streams windowed aggregations default to this model when you configure a timestamp extractor and watermarks.
  • Google’s Dataflow Model is the paper that named event time, watermarks, windows, and triggers as the core streaming vocabulary.
  • Replaying a day of payments through the same job produces the same per-minute totals only if the job windows on event time.

Related glossary terms