System Design of SmartTaxi

SmartTaxi technology is seems simple when A user requests a ride from the app, and a driver arrives to take them to their destination.

But Behind the scenes, however, a giant infrastructure consisting of thousands of services and terabytes of data supports each and every trip on the platform.

Like most web-based services, the SmartTaxi backend system started out as a “monolithic” software architecture with a bunch of app servers and a single database

The system was mainly written in PHP and used Eloquent as the ORM-layer to the database. The original architecture was fine for running a relatively modest number of trips in a few cities.

In the backend of SmartTaxi is now not just designed to handle taxies, instead, it can handle taxi, food delivery and cargo also

The backend is primarily serving mobile phone traffic. uber app talks to the backend over mobile data.

The challenge is to supply on demand

So we need two services

  1. Supply service
  2. Demand service

going forward I will be using supply for cabs and demand for riders while explaining

Supply service:

• The Supply Service tracks cars using geolocation (lat and lang) Every cab which is active keep on sending lat-long to the server every 5 sec once

• The state machines of all of the supply also kept in memory

• To track vehicles there are many attributes to model: number of seats, type of vehicle, the presence of a car seat for children, can a wheelchair be fit, and so on.

• Allocation needs to be tracked. A vehicle, for example, may have three seats but two of those are occupied.

On demand service

• The Demand Service tracks the GPS location of the user when requested

• It tracks requirements of the orders like Does a rider require small car/big car or pool etc

• demand requirements must be matched against supply inventory.

Now we have supply and demand.

This service runs on hundreds of processes.

Core requirements of the dispatch system

  1. reduce extra driving.
  2. reduce waiting time
  3. lowest overall ETA

How does the Dispatch system work??

  1. The earth is a sphere. It’s hard to do summarization and approximation based purely on longitude and latitude. So Uber divides the earth into tiny cells using the Google S2 library. Each cell has a unique cell ID.
  2. S2 can give the coverage for a shape. If you want to draw a circle with a 1km radius centered on London, S2 can tell what cells are needed to completely cover the shape

  1. Since each cell has an ID the ID is used as a sharding key. When a location comes in from supply the cell ID for the location is determined. Using the cell ID as a shard key the location of the supply is updated. It is then sent out to a few replicas.
  2. To match riders to drivers or just display cars on a map, system sends a request to geo by supply
  3. the system filters all cabs by rider’s GPS location data to get nearby cabs that meet riders requirements Using the cell IDs from the circle area all the relevant shards are contacted to return supply data.
  4. Then the list and requirements are sent to routing / ETA to compute the ETA of how nearby they are not geographically, but by the road system.
  5. Sort by ETA then sends it back to supply system to offer it to a driver.

Geospatial data and trips

The design goal is to handle a million GPS points writes per second

Read is even more as for every rider we need to show at least 10 nearby cabs

using Geo hash and Google s2 library all the GPS locations can be queried

Now let's talk about ANALYTICS

Log collection and analysis

Every micro-services or service logging services are configured to push logs to a distributed Kafka cluster and then using log stash we can apply filters on the messages and redirect them to different sources,

for example, Elastic search to do some log analysis using Kibana/Graphana

  1. Track HTTP APIs
  2. To manage profile
  3. To collect feedback and ratings
  4. Promotion and coupons etc
  6. Payment fraud
  7. Incentive abuse
  8. Compromised accounts

Load balance:

Layer 7, Layer 4 and Layer 3 Load Balancer

  • Layer 7 in application load balancing
  • layer 4 is based on IP + ump/ TCP or DNS based load balance
  • Layer 3 is based on only IP address

Post-trip actions:

once the trip is completed we need to do these actions by scheduling

• Collect ratings.

• Send emails.

• Update databases.

• Schedule payments.


The price is increased when there are more demand and less supply with the help of prediction algorithms.

According to SmartTaxi surge helps to meet supply and demand. by increasing the price more cabs will be on the road when the demand is more.



Buy any ready software to boost up your new business to digitalize.