Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
1) User Registration and Authentication :Users (Riders and Drivers) need to create accounts and log in (via email, phone number, or social media).
2) Ride Request and Management:Riders can request a ride with a specified pickup and drop-off location.
3) Real-time Location Tracking:Users should see their current location on the map.
4) Ride History and Ratings:Users should have access to their ride history and be able to rate their experience with driver
5) In app Communication :Enable communication between riders and drivers via in-app chat or call functionality (if necessary)
List non-functional requirements for the system...
1) System should be highly available
2) System should be fault tolorent.
Estimate the scale of the system you are going to design...
Lets assume there are 500 million monthly active users and 100 million daily active users total number of rps =10000*10^6/1000,000
1000 rps lets assume an appliation server can server 50 requests per second then total number servers required =1000/50=200 servers
Lets assume the metadata stored in the database is 2 mb and metadata for chart is 1mb=3mb for a single users in a day
then total number of storage required = 3* 1000*1000*1000,000=3PB total number of storage required for the whole year is 3PB *365 =1095 PB
Define what APIs are expected from the system...
As we don't need datta from multiple sources so grpc will not be required and it very complex to impleent so we will be going throught rest approache and using the HTTP1.1 as we don't need multiplexing so we will be sticking with http1.1
1) POST /v1.0/register -> This api is used to register a user
Host example .com
Body
{
UserName:"",
LastName:"",
PhoneNo:""
}
2) Get/v1/ride -> This api is used to request a ride
Request Parameters - latitude and longitude
Host example.com
3) Real Time Location Tracking - This is a webcsocket call to track the location of the user in real time
Host example.com
4) GET/v1/rideHistory This api takes userId as parameter and output the list of rides
Host example.com
5) In app communication- This is a websocket call for chat between user and driver
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
As system needs to be highly consistent I am planning to use a sql database that provides acid propertites of consistency and for storing the history.
User table
UserId, firstName, lastName
Ride History
UserId, RideId, TimeStamp, Duration,Start,Stop, IsActive
Riders
RiderId, RiderName,isAvaialbe
Each user and one or many rides and each rider has one or more ride history
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
Each user request will be made to dns which will forward the request to the load balaancer the load balancer will then forward the request to one of the web server which will serve static content the request will then be forwarded to api gateway which will forward the request to the api server.
If the users is registering for the first time then the call will go to the register api server which will manage userId, password(hash) or will oauth2 service if user wants to login using gmail or facebbok account. After successfull registration user call will go ride request service In ride request service user geohash will be computed and we will be storing all the available drivers in the cache and their geohash will be calculated then closest max(10 drivers will be displayed to the user based on the geohash and the driver details will be provided ) and the time and price of the ride will also be provided user can select one of the provided rides.After selecting the ride a websocket connection will be established between user and driver so they can chat with each other also for continuously sending location there will be one sse event established between user and rider where user will be continuously provided rider location.For getting the userHistory the call will be made to history api to get the ride history for th user.
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
Each user request will be made to dns which will forward the request to the load balaancer the load balancer will then forward the request to one of the web server which will serve static content the request will then be forwarded to api gateway which will forward the request to the api server.
If the users is registering for the first time then the call will go to the register api server which will manage userId, password(hash) or will oauth2 service if user wants to login using gmail or facebbok account. After successfull registration user call will go ride request service In ride request service user geohash will be computed and we will be storing all the available drivers in the cache and their geohash will be calculated then closest max(10 drivers will be displayed to the user based on the geohash and the driver details will be provided ) and the time and price of the ride will also be provided user can select one of the provided rides.After selecting the ride a websocket connection will be established between user and driver so they can chat with each other also for continuously sending location there will be one sse event established between user and rider where user will be continuously provided rider location.For getting the userHistory the call will be made to history api to get the ride history for th user.
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
Each user request will be made to dns which will forward the request to the load balaancer the load balancer will then forward the request to one of the web server which will serve static content the request will then be forwarded to api gateway which will forward the request to the api server.
If the users is registering for the first time then the call will go to the register api server which will manage userId, password(hash) or will oauth2 service if user wants to login using gmail or facebbok account. After successfull registration user call will go ride request service In ride request service user geohash will be computed and we will be storing all the available drivers in the cache and their geohash will be calculated then closest max(10 drivers will be displayed to the user based on the geohash and the driver details will be provided ) and the time and price of the ride will also be provided user can select one of the provided rides.After selecting the ride a websocket connection will be established between user and driver so they can chat with each other also for continuously sending location there will be one sse event established between user and rider where user will be continuously provided rider location.For getting the userHistory the call will be made to history api to get the ride history for th user.
Explain any trade offs you have made and why you made certain tech choices...
1) Using sql gurantees consistency but suffers from scalabiltiy
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?