Loading...
+Users are able to use an address, to set a location.
+ users get a list of routes to the destination.
+ users are able to follow the route and get a new route if they change it. they're able to see delays in the route.
+ reliability
+ scalability
+ consistency
out of scope:
+ being able to review/see reviews of places
+ Analytics
+ Authentication
+ we expect the system to be able to support hundreds of millions of users.
+ routes should be roughly a few hundred kilometers (same country)
/api/places?keywords=&coordinates [GET]
req:{ a list of keywords to match a place.
coordinates to run a query }
response {
a list of places. the places contain places details and coordinates
}
/api/route [GET]
req: {
coordinates
}
response: {
route steps (a list of route steps for the user to follow
}
/api/navigation [POST] , streaming
req: {
current location
}
response {
traffic update
}
Table Places
PlaceId
Location
Place Name
Place Picture
Index by location, place name
Table Navigations
NavigationId
UserId (or user identifier)
No index, this is more for historic services
1) Users send a request to search for a place. Place service does a matching based on the user location (this is a delimited area based on the user app, they can zoom-in or zoom-out). Then the service runs another search based on keywords, and returns the potential best candidates. Please notes that place can include popular places like restaurants, and destinations.
2) Users get a route to a specific place.
The route service will come up with a list of potential routes for the trip. Then the orchestration service will call the traffic service with the routes. The traffic service will update those routes and will update ETAs. The route service will then re-rank them based on total ETA.
3) Users post their navigation details which are sent to the navigation DB. Users also will get updates from the traffic service for their ETAs.
Route service is a smart dijkstra. Smart meaning that it tries to reduce the number of instructions for a user (nobody wants to navigate 100 small streets over having to navigate a single freeway if the difference is one minute, for example).
Traffic service has real time updates from users. IF we think of the response of route service as a graph with edges and points. Each edge in the response, will have an ETA. The traffic service will determine which edge does a certain point belong to and update the ETA. To do this we can look at expected speed for the edge, and actual average speed of the current users on that edge.
We can expect this DB to be read-intense, since more users will query over the road than users updating the road. The number of users over a certain edge is limited (because it's physically limited over the real world).
To alleviate hotspots we can do this from the DB, for example, instead of storing a freeway as a single entry, we could have multiple entries for the same freeway.
Having an orchestration server at the expense of latency. Allows us to have all the orchestration logic in the server-side, which allows us to push updates to our algorithms faster.
If we let the client have all the orchestration logic, we could run into issues since clients can spend years without updating the app.
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?