本文探讨如何设计大规模的打车应用，如Uber或Lyft。核心功能是预订行程，用户可以请求乘车并匹配附近的司机，看到所有附近的司机，而司机可以选择接受或拒绝乘客的请求。系统需要可扩展性和高可用性。预计在一个区域内有10万活跃司机和100万活跃用户，每秒处理约20万个位置更新和查询，上传带宽约为88MB/s。
title: Notes of System Design No.05 — Design a Uber
description: ‘Design a Uber’
date: 2022-05-14 13:45:37
tags: 系统设计
categories:
- 系统设计
文章目录
00. What is Uber
When it comes to getting about in cities, many people choose ride-sharing apps like Uber or Lyft. Indeed, such apps make short-range commute very easy by offering competitive pricing, reasonably short wait time, and high availability. From a technical point of view, systems like these are very interesting because nearest-neighbor searching is hard. In this article, I want to share my design of large-scale ride-sharing apps like Uber/Lyft.
01.Functional Requirement
Modern ride-sharing apps offer complex features such as carpooling, trip sharing, real-time chat in addition to ride-matching. In this article, I want to keep the discussion brief and focus only on the core functionality — booking a ride. Below are the functional requirements of our system:
-
Users can request a ride and should be matched to a driver in close proximity
-
Users can see all nearby drivers (although not choosing which one)
-
Drivers can answer/decline requests from nearby riders.
-
When a trip is created, both parties see each other’s real-time location.
Needless to say, the system should be scalable and highly available.
02. Non-Functional Requirement
03. Assumptions
Before talking about traffics, let’s examine a unique feature of Uber — its data usage is local. Unlike apps such as Slack or Instagram, inter-region data communication is rarely needed. If you are physically in New York, you can’t book a ride in London. Hence, locational data and trips are not replicated across different regions (less-frequently accessed data such as profiles are replicated globally, of course). In this sense, discussing global traffic is not as meaningful as regional traffic.
The amount of ride requests hitting our system varies depending on the app’s popularity. Here we assume significant regional traffic for a generalized solution:
-
Group cities by proximity into regions. We need maybe a dozen regions to cover the whole of U.S
-
We expect ~100K active drivers in one region.
-
We expect ~1M active users in one region.
-
The total amount of users globally is 10M.
Assume both drivers and riders emit their location ~5s with each message consisting of longitude, latitude, and additional metadata. In addition, riders regularly check nearby drivers (~5s) and sometimes make a ride request. The amount of QPS and bandwidth we can expect are:
-
We expect ~200K location updates/writes per second
-
We expect ~200K queries per second, double it for peak traffic handling.
-
Each location message consists of ID (8 bytes), longitude and latitude (16 bytes), and other info (64 bytes). The total upload bandwidth is just shy of 88MB/s
04. Define API && data model
05. High-Level Design
06. Low-Level Design
扫一扫
330
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
