Katkat

Design a Real-Time Restaurant Analytics Dashboard

Uber FreightSoftware Engineer · Onsite

Last 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:

  1. Data Pipeline: Describe the ingestion flow from the order service to the aggregation layer, including message queuing and stream processing.
  2. Storage Strategy: Propose a schema for the primary database (Long-term storage) and explain how you partition data for write-heavy workloads.
  3. Aggregation Logic: Explain how you handle time-windowing, late-arriving events, and watermarking.
  4. 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).
  5. 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?