Evaluation of Uber Design

Let's evaluate our design for non-functional requirements.

Ensuring non-functional requirements

Let’s evaluate how our system fulfills the non-functional requirements.

Availability

Our system is highly available. We used web socket servers. If a user gets disconnected, the session is recreated via a load balancer with a different server. We have used multiple replicas of our databases with a primary-secondary replication model. We have the Cassandra database, which provides highly available services and no single point of failure. We have used CDN, cache, and load balancers which increase the availability of our system.

Scalability

Our system is highly scalable. We use many independent services so that we can scale them horizontally, independent of each other as per needs. We are using QuadTrees for searching by dividing the map into smaller segments which shortens our search space. We have used CDN which increases the capacity to handle more users. We have used a NoSQL database (Cassandra) which is horizontally scalable. We used Load balancers which improve speed by distributing read workload among different servers.

Reliability

Our system is highly reliable. The trip can continue even if the riders/drivers’ connection is broken by using their phones as local storage. The use of multiple web socket servers ensures smooth, nearly real-time operations. If any of the servers fails, the user will be able to reconnect with another server. We have also used redundant copies of the servers and databases to ensure there is no single point of failure. Our services are decoupled and isolated which eventually increases the reliability. Load balancers help to move the requests away from any failed servers to healthy ones.

Consistency

We have used storage like MySQL to keep our data consistent globally. Moreover, our system does synchronous replication to achieve strong consistency. Because of a limited number of data writers/viewers for a trip (rider, driver, some internal services) using traditional databases does not become a bottleneck (and data sharding in this scenario is easier).

Fraud detection

Our system will be able to detect any fraudulent activity related to payment. We have used the RADAR system to detect any suspicious activity which recognizes the beginning of a fraud attempt and creates a rule to prevent it.

Create a free account to access the full course.

By signing up, you agree to Educative's Terms of Service and Privacy Policy