System requirements


Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...


list parking locations by country, state, city

book a reservation by car type, time, plate number, and location

cancel reservation

make payment

checked in

checked out


Non-Functional:

List non-functional requirements for the system...

high availability

high consistency





Capacity estimation

Estimate the scale of the system you are going to design...

200 parking lot in a country

200 parking spaces in each parking lot

cross 20 countries


each parking lot have about 30 cars in/out per hour


30 * 200 * 20 / 60 / 60 = 2000/60 = 200/6 = 33 rps


data store:

each request will contain

plate number 10 bytes

type 2 bytes

time 8 bytes

location 8 bytes


28 bytes per second,

is about 0.823 gb per year which is very small






API design

Define what APIs are expected from the system...

Get /api/list

  • parameters:
    • country
    • city
    • zipcode


  • response:
    • list
      • location
      • availability
      • business time
      • meta
      • parking lot id

Post /api/reserve

  • payload
    • parking lot id
    • time range
    • plate number
    • car type
    • contact info
  • Response
    • successful
      • session id / payment id
      • reservation id
      • meta （qr code or other instruction）





Post /api/check

  • check in/out
    • event time
    • reservation id / payment id




Database design

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


Parking lot:

  • address
  • business hour
  • lot id
  • meta

parking space:

  • lot id
  • space id
  • support car type
  • location


Vehicle:

  • type
  • plate number
  • vehicle id


Customer:

  • id
  • name
  • phone
  • email


Reservation:

  • plate number
  • reservation id
  • customer id
  • Vehicle id
  • time range
  • status (paid, unpaid, unattend, etc)








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


Payment server

Reservation server

Parking session management server





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


list location --> select location --> book reservation --> make payment --> check in ---> check out






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


Reservation server:

case 1 user did not pay: user can make reservations, the server will hold a short live session to block a parking lot at a time, if user did not pay, it will recycle the session

case 2 user paid, then the even will be send to Parking session management server and parking lot will be blocked

Parking session management server:

case user arrived, it will record check in time, do also do for checkout and if late it will make status as overtime

if user did not arrive, it will update the status of unattend


payment system:

user make payment will be hold, when session is end or is unattended in given window, or checkout with overdue, it will charge with the according payment/late fee





Trade offs/Tech choices

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

the system will lock the parking lot when user did not pay, in this case, if there are a large number of users keep click booking, there will be nothing avalible at that time unless the space is being freed


the system contains manual work, where user may park the car in wrong location, we may need to have some staff to keep our system up to date or install some trcaking devices






Failure scenarios/bottlenecks

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

if the payment system is done, no one will be able to book our system

we use distribution system, and we will have multiple node running for each parking session managment server to ensure high availability.




Future improvements

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

the latency is not under our consideration because qps is low and user will more likey concern about if they can park their car or retrieve thier car. In future we may be able to boot our latency and make use of ai to predict lilely avalibility of each parking lot to support more customers in given time