## Scenario Design a service that continuously displays the ten restaurants with the most completed orders during the trailing one-hour window. Updates within a few seconds are acceptable, and approximate counts are allowed when they materially reduce resource use. Order events can arrive late or more than once. A later extension must provide the top ten within each city rather than one global list. ### Constraints & Assumptions - Each event has a unique event ID, restaurant ID, city, event time, and completion state. - The window is based on event time, not consumer arrival time. - The display refreshes frequently, but recomputing all one-hour counts from raw events on every request is unacceptable. - The design must state a lateness policy, deduplication horizon, and whether results are exact or approximate. - Historical replay and recovery after a stream-processor failure are required. ### Clarifying Questions to Ask - What peak event rate and number of active restaurants should be assumed? - How late may an event arrive, and can an already displayed result be corrected? - Is approximate ranking acceptable only near the tenth-place boundary or for every count? - How should cancellations or corrected orders affect prior counts? - Is the city dimension attached to the restaurant or captured on each order event? ```hint Make expiration incremental Keep short event-time buckets so advancing the window adds one bucket and subtracts the expired bucket rather than reading the whole hour. ``` ```hint Separate counting from ranking Partitioned counters can update restaurant totals, while a second stage maintains local candidates and merges them into a global top ten. ``` ### What a Strong Answer Covers - A durable event stream, stable event IDs, event-time watermarks, and bounded deduplication. - Minute or finer buckets whose expiration produces a true sliding-hour result. - Partitioning, hotspot mitigation, local top candidates, and a bounded global merge. - An explicit exact design and a defensible approximate alternative such as a sketch plus candidate verification. - Checkpointing, replay, idempotent state updates, and treatment of late events and corrections. - A query-serving representation with versioned snapshots and clear freshness metadata. - Metrics for lag, watermark delay, duplicates, dropped-late events, state size, skew, and rank churn. - A city-keyed extension that preserves isolation and prevents unbounded fan-out. ### Follow-up Questions 1. Does summing sixty one-minute buckets produce an exact sliding hour at every second? 2. In which direction does a Count-Min Sketch err, and how could that affect rank ten? 3. How would a single extremely popular restaurant overload a partition? 4. How would a cancellation retract an order that is still inside the window? 5. What state must be restored before replaying from a checkpoint?