Uber是一个共享汽车平台，连接了乘客和利用自有车辆提供交通服务的司机。它允许用户在手机上预定出行需求，匹配附近的司机，可以带乘客从他们的位置到目的地的司机。
Functional Requirements
- 乘客可以输入他们的起始位置和目的地，然后得到一个预估价格
- 乘客可以可以根据这个预估价格发起接单请求
- 乘客可以根据这个请求，匹配到一个司机，在附近且当前有空的司机
- 司机可以接受或拒绝这个接单请求，然后通过导航接乘客或放下乘客
Non-Functional Requirements
- 系统应该是低延迟匹配
- 系统应该保证强一致性在乘客司机匹配时，避免任何司机在同一时间匹配到多个乘客
- 系统应该能够处理高吞吐量，特别是在高峰时段或特殊事件
Core Entities
- 乘客（rider): 可以包含个人信息，名字，联系方式，支付方式等等
- 司机（driver): 可以包含个人信息，车辆信息，当前可用状态等
- 票价（fare): 包含乘客，起始位置，目的地，预估票价等
- 行程（trip): 包含乘客，司机，起始位置，目的地，价格等信息.
- 位置（location): 包含经纬度信息，可以用来表示乘客和司机的位置
接着我们按顺序解决每个功能需求。这种循序渐进的方法将帮助我们有效地保持重点和管理范围，确保系统架构的构建具有凝聚力。
API or System interface
1. 获取预估票价
POST /fare -> Fare
Body: {
pickupLocation,
destination
}2. 确认乘车请求
乘客在查看估计票价后使用此端点来确认其乘车请求。它通过向后端发出信号来寻找合适的司机来启动乘车匹配过程，从而创建一个新的乘车对象。
POST /rides -> Ride
Body: {
fareId
}3. 更新司机位置
在我们匹配乘客和司机之前，我们需要知道司机的位置，这个接口用来实时更新司机的位置。司机客户端会定时调用这个接口来更新位置。
POST /drivers/location -> Success/Error
Body: {
lat, long
}4. 接受乘车请求
这个接口用于司机接受或拒绝请求，如果接受了，系统会更新trip状态，然后司机可以导航到乘客的位置。
PATCH /rides/:rideId -> Ride
Body: {
accept/deny
}High Level Design
乘客可以输入他们的起始位置和目的地，然后得到一个预估价格
第一件事情，当用户想要打开应用发起叫车时，是搜索目的地。此时，客户端发起一个请求到服务端获取预估价格用于ride。用户有机会发起一个ride with this fare 或者什么也不做。
核心组件，完成必要估算是：
- Rider Client: 客户端
- API Gateway：
- Ride Service
- Third Party Mapping API:
- Database:
Let's walk through exactly how these components interact when a rider requests a fare estimate:
- On the client app, the rider enters their pickup location and destination, which send a post request to our service.
- Before forwarding the request to the Ride service, the api gateway receives the request and handles any necessary authentication and rate limiting.
- The Ride service makes a request to the third party mapping api to calculate , between the pickup and destination locations the distance and time.