Data footprint in Uber/OLA || System Design || iOS

Let’s assume Uber/Ola has 10 million bookings per day. Each booking generates 3MB of data.

So we will require 10 Million * 3 MB = 30 Million MB = 30,000,000 Mb = 30,000 GB = 30 TB of data. ~= $680

If you have to store 52 TB (53248 GB) of data in Standard storage class in N.Virginia region, you will pay the following amount per month:

$0.022 * 53248 = $1 171.46

Apart from storage cost, there is an additional cost that plays a critical role:-

• Requests and data retrievals
• Data transfer
• Management and analytics
• Replication/Snapshot
• Backup
• Number of servers
• Processing data

Let’s analyse how we can reduce data footprint in iOS applications:-

Driver

Before booking:-

Ideal State:-

• Most of the time driver do not moves when there is no ride. In such situations, we can stop location updates to the server.
• Start Monitoring Significant Location Changes

Moving State:

• We can opt-out region based location updates. So whenever there is an update in the region, the driver will notify the location to the server.

After booking:-

• Generally, there is 2–5km distance between the pickup point and to driver’s acceptance location. After the driver accepts the ride, he receives a path to move from its location to the user’s location. Instead of sending data regularly to the server, we can track if is there any diversion in the driver’s car path and path received from the server. If it goes well then it is not necessary to send any data to the server. If it goes other around then we can notify the server and end user.
• When the driver reaches near to the rider then we can enable the real-time update to the server.

After pickup by the rider:-

• The driver can Start Monitoring Significant Location Changes. As riders don’t need regular updates on location. If the rider has shared and opts for regular updates of location then the Driver needs to stop Monitoring significant location changes.
• The rider tends to see the location update on the map. Whenever it is near to the destination then, we can start regular updates of the location to the server.
• We can opt out of similar logic on the mobile side to compare the path that needs to be traveled and the moving point. If the driver is moving according to the path traced then we can stop location updates to the server.

Rider:-

After booking

As driver need to know correct location of the rider, we cannot stop location update to the server. But if the driver is far away then we can stop location update of rider.

After starting trip

Both rider and driver will contain same location, thus we can stop rider location update.

We can approximately save 2MB of data for each ride.

So we will require 10 Million * 1 MB = 10 Million MB = 10,000,000 Mb = 10,000 GB = 10 TB of data. ~= $225

We have reduced costing by 66%