Process Sharded Login Logs
GoogleSoftware Engineer · OnsiteLast updated
This problem tests your ability to design a robust data pipeline for processing sharded, potentially out-of-order login logs from a distributed system.
Problem Statement
You are tasked with building a processing module that consumes login events from multiple independent shards. Each shard emits logs sequentially, but network delays and system rebalances mean logs across different shards may arrive out of chronological order. Additionally, logs may be duplicated due to retry mechanisms in the upstream producers.
Requirements:
- Deduplication: Each log entry contains a unique
request_id. You must ensure eachrequest_idis processed exactly once. - Ordering: You must output login events in the correct chronological order based on the
timestampfield. - Late-event Handling: Events may arrive with a delay of up to
Tseconds. You must buffer incoming events until you are confident no earlier events are pending.
Function Signature:
Implement a class LogProcessor with the following methods:
class LogProcessor:
def __init__(self, buffer_time_seconds: int):
# buffer_time_seconds defines the threshold for late events
pass
def process_event(self, event: dict):
# event format: {'request_id': str, 'timestamp': int, 'user_id': str}
# Add event to the pipeline
pass
def get_ordered_logs(self) -> list:
# Returns and clears logs that are safe to emit based on buffer_time
pass
Constraints:
- Assume
timestampis a Unix epoch integer. buffer_time_secondsensures that if you receive an event at timet, you will not receive an event withtimestamp < (t - buffer_time_seconds)in the future.- The system must handle high throughput; minimize memory usage where possible.
Example:
If buffer_time_seconds is 5 and you receive events at times 100, 103, 101, when a new event arrives at 106, you can safely output events 100, 101, 103 because 106 - 5 = 101, and you are guaranteed no more events before 101 will arrive.
Edge Cases to Consider:
- Events arriving with identical timestamps.
- Large gaps in log ingestion (idle periods).
- System crashes (how do you maintain state for deduplication?).
Hints
Hint 1
Use a Hash Set or Bloom Filter to keep track of processed `request_id`s for deduplication.
Hint 2
Maintain a Min-Heap (priority queue) to store events ordered by their timestamp for efficient retrieval.
Hint 3
Use a high-water mark (the timestamp of the latest received event) to calculate the cutoff point for emitting logs from your buffer.
Follow-up questions
- How would you handle the 'exactly-once' processing requirement if the worker node crashes mid-process?
- How does the choice of buffer duration (T) trade off between system latency and data completeness?
- If the number of events per second increases by 1000x, what components of this design would become bottlenecks?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.