What is Event Time vs Processing Time?

Core Definition
In distributed stream processing systems, Event Time is when something actually happened in the real world (embedded in the event payload), while Processing Time is when your system processes that event (based on the machine clock doing the work).
The Fundamental Problem: Time is ambiguous in distributed systems. When a user clicks a video or requests a ride, that action generates an event at a specific moment. But the event must travel through networks, queues, and processors before your system sees it. Seconds or even minutes may pass between event generation and processing.

If you build metrics, billing, or anomaly detection without being explicit about which time notion you use, you get silently wrong results.

Event Time in Detail: This is the timestamp representing when something occurred in the real world. For example, when a rider requested a trip at 3:45:23 PM, that timestamp is immutable and embedded in the event. Event time is what business stakeholders care about: revenue per hour, rides per city per 5 minutes, or video plays per title should all be computed by when they actually occurred.

Processing Time in Detail: This is when your stream processor handles the event according to its wall clock. If that rider's event arrives at your processor at 3:45:27 PM (4 seconds later), that is the processing time. Processing time is cheap and always available, but it is non deterministic. Network delays, retries, or backpressure can cause the same event to have wildly different processing times.

❗ Remember: In a live system under load, median processing delay might be 200 milliseconds, but 99th percentile could be multiple seconds or minutes. This gap between event time and processing time is why the choice matters.

Modern stream processing architectures must choose which notion of time anchors their logic. That choice affects everything: windowing, aggregations, alerting, billing, and how you handle late or out of order events.

💡 Key Takeaways

✓Event time represents when something actually happened in the real world and is embedded in the event payload as an immutable timestamp

✓Processing time is when your system processes the event based on the wall clock of the machine doing the work

✓The gap between event time and processing time is unpredictable: median might be 200 milliseconds but 99th percentile can reach multiple seconds or minutes due to network jitter and backpressure

✓Using processing time for business metrics like revenue per hour or user actions per minute produces silently wrong results when network delays or system load varies

📌 Examples

1A rider requests a trip at exactly 3:45:23 PM. Due to mobile network delays, the event reaches your stream processor at 3:45:27 PM. Event time is 3:45:23, processing time is 3:45:27.

2During a regional network outage, events might be delayed by several minutes. If you use processing time windows, you see a false dip during the outage, then an artificial spike when connectivity is restored and the backlog flushes.

← Back to Event Time vs Processing Time Overview