Design a Real-Time Restaurant Analytics Dashboard
Uber FreightSoftware Engineer · OnsiteLast updated
This problem tests the ability to design a distributed, low-latency analytics pipeline capable of handling high-throughput event ingestion, time-windowed aggregations, and efficient cache retrieval.
System Design: Real-Time Restaurant Analytics Dashboard
Design a backend architecture for a dashboard that provides real-time analytics for a global food delivery platform. The system must track total order volume, gross revenue, and the top-selling dishes across three sliding time windows: 1 hour, 1 day, and 7 days.
Requirements
- Scale: Ingest 100,000 orders per second globally.
- Latency: Dashboard widgets should reflect data with a maximum delay of 5 seconds.
- Granularity: Support per-restaurant and aggregate (platform-wide) views.
- Availability: The system must handle transient traffic spikes without losing order events.
What your answer should cover:
- Data Pipeline: Describe the ingestion flow from the order service to the aggregation layer, including message queuing and stream processing.
- Storage Strategy: Propose a schema for the primary database (Long-term storage) and explain how you partition data for write-heavy workloads.
- Aggregation Logic: Explain how you handle time-windowing, late-arriving events, and watermarking.
- Cache & API: Define a Redis key design that allows for efficient retrieval by the dashboard for different time windows and scope levels (restaurant vs. global).
- Scalability: Describe how to handle system failures and how to recompute the cache if the state becomes inconsistent.
Hints
Hint 1
Consider using a distributed stream processing engine like Apache Flink or Spark Streaming to perform windowed aggregations on event streams.
Hint 2
Use a tiered storage strategy where raw events are stored in an immutable log (like Kafka) and aggregated metrics are persisted in a time-series database or pre-computed Redis caches.
Hint 3
For top-selling dishes, explore the use of heavy-hitters algorithms or sketches (like Count-Min Sketch) to estimate popularity at scale if exact counts become too expensive.
Follow-up questions
- How would you handle a scenario where a restaurant needs to perform a bulk cancellation of orders, and how does that affect your rolling 1-hour metric?
- If the latency requirements were lowered to 500ms, what specific architectural changes would you make to your ingestion and cache layers?
- How would you ensure data consistency between your real-time cache and the source-of-truth database during a regional outage?
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.