Uber Eats System Design Interview: A Pro Grade Answer for SDE NG

Uber Eats System Design Interview: A Pro Grade Answer for SDE NG

[!NOTE] System Design 是 SDE 面试中的分水岭。很多 New Grad 以为只要刷 LeetCode 就能过，但在 Uber 这种大厂，System Design 往往决定了你的 Level。

本文复盘一道 Uber 以及 Uber Eats 常见的高频 System Design 面试题：Design a Food Delivery App (like Uber Eats)。

1. Requirement Analysis (Clarification)

不要一上来就画图。先问清楚需求，展示你的 Product Sense。

• Functional Requirements:
  • Users can search for restaurants.
  • Users can place orders.
  • Restaurants can receive and update order status.
  • Drivers (Couriers) can receive order requests and update location.
• Non-Functional Requirements:
  • Low Latency: Real-time updates for order status and driver location.
  • High Availability: System should always be up (CAP Theorem usually trade-off C for A in some parts, but Consistency is key for payments).
  • Scalability: Handle peak hours (Lunch/Dinner).

2. High-Level Design (Architecture)

展示你对 Microservices 架构的理解。

• API Gateway: 作为系统的入口，处理 Authentication, Rate Limiting, Routing。
• Service Breakdown:
  • User Service: User profile, preferences.
  • Restaurant Service: Menu management, restaurant availability.
  • Order Service: Order lifecycle management (Created -> Paid -> Cooking -> Picked Up -> Delivered).
  • Driver Service: Driver matching, location tracking.
• Database:
  • RDBMS (PostgreSQL/MySQL): 这里的 Transaction 很重要 (ACID)，适合存 User, Order, Payment 数据。
  • NoSQL (Cassandra/DynamoDB): 适合存大量且 schema 灵活的数据，或者用于 Driver Location History。
  • Redis: Caching menu items and restaurant status for low latency.

3. Deep Dive: Driver Matching (The Core)

这是 Uber Eats 的核心难点。

• Geospatial Indexing: 怎么快速找到附近的司机？
  • QuadTree 或 Google S2 Library。不要只说 "Find nearby"，要具体到数据结构。
  • Redis 有内置的 GEO commands，也是一个可选项。
• Matching Algorithm:
  • Simple: Find nearest available driver.
  • Advanced: Consider Estimated Time of Arrival (ETA), batching orders (drivers picking up multiple orders), driver preferences.

4. Deep Dive: Real-time Updates

怎么让用户实时看到司机的位置？

• Polling vs. WebSocket:
  • Short Polling: Client 每隔几秒发请求。简单但效率低，服务器压力大。
  • Long Polling: 好一点，但还不够。
  • WebSocket: Best Solution for real-time bi-directional communication. Server pushes updates to Client.
• Kafka: Use Kafka as a message queue to handle the stream of location updates from drivers to the Driver Service, then to the tracking/notification system.

5. Summary

一个 Pro Grade 的回答不仅是把组件堆上去，而是要解释 Trade-offs。

• 为什么选 SQL 而不是 NoSQL？(Need ACID for orders)
• 为什么选 WebSocket？(Real-time experience)
• 如何处理 High Traffic？(Load Balancer, Caching, Database Sharding)

准备 System Design 就像搭积木，关键在于你知道每块积木（组件）的特性，并能根据图纸（需求）把它们稳固地搭起来。