Design out-of-order windowed stream processor evaluates algorithm design, data structures, correctness, complexity, edge cases, and implementation details in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
##### Question
Design an event processor for an unbounded, infinite stream of events. Each event has the fields `id`, `timestamp`, `payload` (a string), and `checksum`. Events may arrive out of timestamp order, and they should drive a rolling aggregate over a 1-minute (60-second) sliding window.
Your processor must:
1. **Validate each event by its checksum** and discard any event whose checksum does not match its payload.
2. **Drop late and out-of-window events** — any valid event whose timestamp falls more than 60 seconds behind the current window (the latest observed timestamp) is discarded.
3. **Handle duplicates** — if the same event `id` is seen more than once, it must only be counted once.
4. **Maintain and report the average payload length over the latest 60 seconds**, updating continuously as new events arrive and as old events fall out of the window.
5. Keep the **overall time complexity no worse than O(n log n)** across `n` events.
Describe the data structures you would use, how you keep the window current as the clock advances, and how you handle late arrivals and duplicates.
Overview: Design out-of-order windowed stream processor evaluates algorithm design, data structures, correctness, complexity, edge cases, and implementation details in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
Design an event processor for an unbounded, infinite stream of events. Each event has the fields id, timestamp, payload (a string), and checksum. Events may arrive out of timestamp order, and they should drive a rolling aggregate over a 1-minute (60-second) sliding window.
Your processor must:
Validate each event by its checksum
and discard any event whose checksum does not match its payload.
Drop late and out-of-window events
— any valid event whose timestamp falls more than 60 seconds behind the current window (the latest observed timestamp) is discarded.
Handle duplicates
— if the same event
id
is seen more than once, it must only be counted once.
Maintain and report the average payload length over the latest 60 seconds
, updating continuously as new events arrive and as old events fall out of the window.
Keep the
overall time complexity no worse than O(n log n)
across
n
events.
Describe the data structures you would use, how you keep the window current as the clock advances, and how you handle late arrivals and duplicates.
Clarifying Questions to Ask Guidance
Clarify input sizes, value ranges, mutability, return format, and tie-breaking.
State the target time and space complexity before coding.
Call out edge cases such as empty inputs, duplicates, invalid values, overflow, and boundary sizes.
What a Strong Answer Covers Guidance
A clear algorithm with the right data structures and enough pseudocode or code-level detail to implement it.
A correctness argument that explains why the algorithm covers all required cases.
Time and space complexity, plus at least one alternative approach when relevant.
Focused tests for normal cases, edge cases, and failure modes.
Follow-up Questions Guidance
How would the approach change if the input were streaming or too large for memory?
What invariants would you assert in production code?
Which tests would catch off-by-one, duplicate, or tie-breaking bugs?