Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)
-layout
-traffic flow
-reservation
-security
-cost
List non-functional requirements for the system...
-easy to get in and out
-safe
Estimate the scale of the system you are going to design...
-this should handle the amount of parking spots needed.
Define what APIs are expected from the system...
we need APIs for the following things:
-Reservations
-Transactions
-Pricing/Purchases
-Parking layout
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...
we need entities for the following items:
Spots
Reservation
Transaction
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...
Client can make reservation with the reservation API. Reservation API will store reservation in reservation DB. Reservation can get the pricing info for the reservation from the pricing service. A cron job can be scheduled when the reservation occurs to call the Transaction Service to log that transaction in the DB. Transaction service can also be used for on-demand people coming to the parking lot. When a person leaves the lot, transition service will update the transaction db. Cache can be used for pricing service since the info should be very static.
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.
-to create/modify the lot, parking layout service can be hit with a POST or PUT.
-When someone comes to the parking lot, the transaction service will be hit with a POST to create a new transaction record.
-When someone wants to get/create/update/delete a parking lot reservation, they will hit a GET/POST/PUT/DELETE to the reservations API. This will schedule a cron-job on POST/PUT to call transaction db to store the transaction.
-Pricing api can be used to get and set pricing info..
-When someone leaves the parking lot, transaction api can update the record.
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...
Explain any trade offs you have made and why you made certain tech choices...
-Reservations and Transactions are separate but connected. May cause some data syncing issues if not kept in check.
-Pricing is a potential bottleneck as it is hit by many services. Will likely be read-heavy, so cache should be used to help performance.
Try to discuss as many failure scenarios/bottlenecks as possible.
-Pricing system goes down and now we cannot track costs.
-Cron job between Reservations and Transactions database could fail and we lose tracking reservations in the transactions db.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
Reservations and Transactions could have a distributed queue or something to make it easier to keep the items in-sync.