Stream Processing Architectures • Windowing & Time-based AggregationsMedium⏱️ ~2 min
Event Time vs Processing Time: The Foundation of Windowing
The Two Clocks Problem: Every streaming event exists in two timelines. Processing time is when your system ingests the event (wall clock on your server). Event time is when the event actually occurred (timestamp embedded in the payload, like when a user clicked or a sensor measured).
This distinction matters enormously. Imagine mobile payment events. A user makes a purchase at 3:00 PM but their phone has spotty connectivity. The event reaches your system at 3:08 PM. If you use processing time, this purchase counts toward the "3:05 to 3:10 window." If you use event time, it correctly counts toward the "3:00 to 3:05 window."
Processing Time Advantages: Simple implementation, low latency results (sub second p99), and no need to handle out of order events. Your window closes when the wall clock says so. Perfect for operational monitoring where you care about "what is happening right now" rather than precise historical accuracy.
Event Time Advantages: Stable, reproducible metrics even when data is delayed or reprocessed. If you replay events from a log, you get identical results. Critical for business logic like billing, compliance reporting, or any analytics where correctness trumps speed.
The catch with event time is managing out of order arrival. At a payment provider handling 100,000 transactions per second, events might arrive with this distribution: 90 percent within 2 seconds, 99 percent within 30 seconds, but some delayed by minutes due to retries or mobile connectivity issues.
Watermarks Bridge the Gap: A watermark is the system's assertion that "I have seen all events up to event time T." For example, a watermark of 12:05 with 2 minutes allowed lateness means the system believes all events with timestamps up to 12:03 have arrived. Windows can now close deterministically based on event time while still making progress.
Typical Event Arrival Distribution
90%
WITHIN 2 SEC
99%
WITHIN 30 SEC
1%
MINUTES LATE
⚠️ Common Pitfall: Aggressive watermarks (low allowed lateness) drop late events silently. If 2 percent of events arrive more than 5 minutes late but you only allow 3 minutes, your metrics will consistently undercount by 2 percent.
In practice, Uber's real time feature platform uses event time windows with watermarks to compute features like "driver cancellations in last 10 minutes." Even when backfilled or delayed events arrive hours later, they correctly update the aggregations, ensuring model training and inference use accurate data.💡 Key Takeaways
✓Processing time is when your system sees the event (low latency, simple, but distorted by network delays and outages), while event time is when the event actually occurred (stable metrics, but requires handling out of order arrival)
✓At scale, typical distributions show 90 percent of events arrive within 2 seconds, 99 percent within 30 seconds, but some delayed by minutes due to retries or connectivity issues
✓Watermarks enable event time processing by asserting "all events up to time T have arrived," allowing windows to close deterministically while making forward progress
✓Aggressive watermarks with low allowed lateness can silently drop late events, causing systematic undercounting; if 2 percent arrive after your lateness threshold, metrics will be off by 2 percent continuously
📌 Examples
1A payment processor uses event time windows so that a transaction at 3:00 PM delayed until 3:08 PM still counts in the correct 5 minute window, ensuring accurate fraud detection patterns
2Uber's Michelangelo platform uses event time with watermarks to compute driver cancellation rates over 10 minute windows, allowing backfilled events from hours ago to correctly update aggregations
3Processing time windowing is used for operational dashboards showing "current requests per second" where immediacy matters more than perfect historical accuracy