I would probably divide up the architecture into the following pieces:
- Driver App
- Passenger App
- Backend Server
Let’s architect out the driver experience first. Drivers need to be onboarded so figure a whole system just for onboarding a driver. Once drivers are in the system we need to be able to track their location whenever they are ready to accept rides. So the app at a bare minimum needs to be able to constantly relay the driver’s current location to the backend server.
This needs to be updated in real time. I may look toward a messaging bus/queue for these types of updates so I can throw location updates out if get too behind. I would look at how multiplayer games like Quake implemented reporting real time location to the server as fast as possible and with as little delay as possible.
Once the backend server has the location we can look to the passenger app to do almost the same thing. The passenger app at a minimum needs to report trips that people want to take. Basically source and destination location.
Once we have both in the system we can now creating a matching algorithm or module. I would base this on how stock markets match and route orders. There are a number of different techniques for this. I would model the drivers as ask orders and the passenger requests as buy orders. Once a driver has been matched to a passenger we can send them both notifications and provide updates along the way.
Keep in mind that this is really only for traditional Ubers with one passenger. With pools the matching algorithm becomes more complex as well as the infrastructure to support it.
