System requirements


Functional:

  1. able to check available parking spots at a given time
  2. able to reserve a parking spot
  3. able to mark parking spots as vacant/taken
  4. able to process transactions
  5. able to save car info if wanted
  6. ordering guarantee, whoever books a spot first should get the spot


Non-Functional:



Capacity estimation

Assuming the parking lot has 20000 spots

  1. the system should be able to handle 2k requests per minute






API design

Define what APIs are expected from the system...






Database design

Tables we need:

  • reservations
    • id
    • reservation_start_time
    • reservation_end_time
    • reservation_made_at
    • parking_spot_id
    • user_id
    • car_id
    • payment_status
  • parking spots
    • id
  • user account
    • id
    • password
  • user cars
    • id
    • plate_number
    • colour
    • model




High-level design

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...


We could have a reservation API the UI talks to and does the following:

  • requires input - reservation start time and duration
  • check if any spot is available by querying the reservations table
  • creates a record in the reservations table with a pending payment status
  • takes user to payment page, upon successful payment, mark record with a success payment status
  • return the parking spot reserved

when a user enters a parking lot without a reservation, we ask them to pay upfront and create a reservation record.


For a cancellation flow, we could simply delete the reservation record by ID.





Request flows

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...

ordering is guaranteed because we create a reservation record right away




Detailed component design

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...


The bottleneck in this system is the reservations table since it's the source of truth of what's available and when and gets queried a lot. It has both heavy reads and writes. We could potentially shard it based on location, so that each location has one reservations table.


We can also add a load balancer for the reservation API so that the user requests can get routed to the one of the many API servers .



Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...


NoSQL could be more scalable but we require the structure of a RDBS for the fast queries.





Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.






Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

show all the spots available to user and allow them to choose one they like.