Watermarks and Windows — Stream Processing Vocabulary
Learn vocabulary for event time vs. processing time, watermarks, tumbling windows, sliding windows, session windows, and late data handling.
0 / 10 completed
1 / 10
What is the difference between 'event time' and 'processing time' in stream processing vocabulary?
Event time (embedded in the record payload — e.g., sensor timestamp): when the event actually occurred. Processing time (wall clock of the processing engine): when the event was processed. They diverge due to network delays, retries, or backfill. Event-time semantics give correct results (e.g., revenue per hour) regardless of when data arrives; processing-time semantics are simpler but produce incorrect results for late or out-of-order data.
2 / 10
What is a 'watermark' in stream processing vocabulary?
Watermarks (Flink, Beam, Dataflow): the engine generates a watermark W(t) meaning 'I believe all events with event_time < t have been received.' When the watermark passes a window's end time, the engine closes the window and emits results. Watermarks are heuristic — they allow some late-arriving data tolerance. A watermark that is too aggressive causes incorrect results; too conservative causes high latency.
3 / 10
What is a 'tumbling window' in stream processing vocabulary?
Tumbling windows: fixed duration, no overlap. Every event belongs to exactly one window. Ideal for aggregations like 'total orders in each 1-hour period.' Simple to reason about and compute. Contrast with sliding windows (overlap) and session windows (dynamic, gap-based). Common in billing, reporting, and rate calculations.
4 / 10
What is a 'session window' in stream processing vocabulary?
Session windows are key for behavioral analytics: group all events from a user/device into a 'session' separated by periods of inactivity. If a user clicks at 2:00, 2:05, 2:08, then nothing until 3:00, and the gap timeout is 15 minutes, you get one session [2:00-2:08]. Sessions have variable duration — unlike tumbling or sliding windows. Useful for clickstream analysis, user journey aggregation.
5 / 10
What is 'late data handling' in stream processing vocabulary?
Late data is inevitable: mobile apps buffer events offline, network delays vary, clock skew exists. Strategies: (1) Allowed lateness — keep the window open extra time after the watermark passes (emit updated results). (2) Side outputs / dead-letter — route late events to a separate stream for reprocessing or alerting. (3) Drop — acceptable when late data is rare and approximate results suffice. Choice depends on correctness requirements.
6 / 10
Code Review Comment: Alex writes in the code review:
'I'm seeing a high volume of 'late data' events for user profile updates. The system is struggling to process them within the tumbling window. Could you investigate why these events are arriving so late and consider adjusting the window size or using a different windowing strategy?'
This question tests understanding of 'late data handling' within the context of a code review. The user is highlighting that events are arriving *after* the tumbling window, which is the core issue causing problems. It's crucial to differentiate between late *data* (invalid values) and late *arrival* of data relative to the window.
7 / 10
Slack Message: Sarah from the streaming analytics team sends this message:
'Hey team, we're experimenting with using a session window to analyze user engagement. The goal is to group events belonging to the same user session and calculate metrics like average session duration. Has anyone had experience with this approach?'
This tests understanding of 'session windows'. A key characteristic of session windows is that they group events together based on user activity over time. It's important to recognize this differs from tumbling or fixed-size windows which operate on strict time intervals. The message's context highlights the use case.
8 / 10
PR Description: You are updating a stream processing pipeline configuration to use a fixed-size tumbling window with a duration of 5 minutes. Your team lead comments:
'Excellent! Remember that the tumbling window will continuously reset every 5 minutes, discarding any events older than that period. This is good for capturing bursty data but might miss longer trends.'
This question focuses on the resetting behavior of a fixed-size tumbling window. The key point to understand is that the window *discards* older data every 5 minutes; it doesn't accumulate indefinitely. This makes it suitable for capturing bursts but not long-term trends.
9 / 10
Standup Update: During the daily standup, David says:
'We're currently using a 'tumbling window' to calculate real-time clickstream metrics. We're observing some challenges with data skew, particularly during promotional events where there are sudden spikes in traffic. We're investigating strategies for handling these peaks.'
This question tests understanding of how tumbling windows relate to data skew. Tumbling windows are well-suited for handling variable event rates because they reset every fixed period. However, the challenge highlighted (promotional events) is a common issue when using this type of windowing strategy.
10 / 10
API Response: You receive the following API response related to stream processing metrics:
{
"window_type": "session",
"window_size": "15 minutes",
"event_count": 1234,
"average_duration": 8.7,
"max_duration": 60}
What does the 'session' window type most likely represent?
The 'session' window type indicates that events are grouped based on user activity over time. This contrasts with tumbling windows which reset at fixed intervals. The API response provides key metrics (count and average duration) relevant to this session-based analysis.
What will I learn from the "Watermarks and Windows — Stream Processing Vocabulary" exercise?
Learn vocabulary for event time vs. processing time, watermarks, tumbling windows, sliding windows, session windows, and late data handling.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Streaming Data exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss streaming data topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Streaming Data exercises?
See the full Streaming Data exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.