System requirements

Functional:

• allow vehicle to enter and exit efficiently
• track times of each vehicle
• allocate parking spaces by size and availability
• intake payment including hourly rate calculation
• reservation system
• security features
• UI for driver to navigate the system
• reporting

Non-Functional:

• security
• reliability
• user experience

Capacity estimation

total parking spaces 500 in total and average 350 unique cars per day

API design

POST: /parking_spot/{car_type}

• post data: with license plate number
• generate a ticket number
• should return a range of where the car should park

GET:/parking_fee/{ticket_number}

• should return data for how much the parking fee is for the car

GET:/pay_parking/{ticket_number}

• should return 200OK if paid parking

POST:/reserve_parking

• data in request to contain:
• number reserved for each type of car
• returns 200 OK

GET: /availability/

• returns the map of the parking lot

GET: /usage/{date_range}/{car_type}

• returns the revenue data for analytics
• returns paginated usage data

Database design

Table:

• car:
• int: ID
• string: license_plate
• id: car_type_id
• datetime: created_at
• usage:
• int: car_id
• datetime: entry_time
• datetime: exit_time (nullable)
• boolean: payment_status
• int: parking_range
• money: fees_charged
• car_type:
• int: ID
• string: car_type
• money: rate

the database should be relational database because the data is structured and it would be less costly to query from relational database

High-level design

    B[client] --> C{server}

    C --> D[Database]

    C --> E[Payment System]

    F[Security] --> C

Request flows

User drives through parking lot and requests a ticket from the machine, this is the Client. Client would get data from the server regarding where the car should be parked. Server would contain algorithm about where the best parking spot would be and return a good parking range for the car and create a parking id. Server would also store necessary information into the database.

Once user is ready to leave, user uses the parking machine to leave the parking lot, this would get from server to get the amount to be paid. Then client can post to server with information and server would forward that information to the payment service. Once payment service confirms payment, we store that in the system and lets the car out.

Client should then communicate directly with payment system to pay and once payment system says ok, we store that information back to server and database

Detailed component design

Algorithms for calculating the best place to park.

• we should first map out the parking lot and create parking ranges and rankings such that there are ranges that are easier to park than others.
• as the cars come in, we should fill in the ones closer to entrances and exits first to allow convience
• we should also build in logic so that multiple cars that are coming in don't get assigned all to the same range which makes it crowded for parking and reduces convience.
• 
  

Trade offs/Tech choices

• we could have the credit card information be encrypted and passed through the server to the payment system, this way we can obtain more information about our client
• But this poses added security risks since we are storing sensitive information and would require more client permission
• this would also add a layer for possibility for failure since now payment depended on server to work
• therefore, we made the decision to let the client communicate directly to payment system and then back again to server

Failure scenarios/bottlenecks

In case where the payment system fails, we should have a mechanism to let the cars leave and pay later.

Servers can be hosted in multiple locations to prevent single point of failure.

Database can be distributed with one main database. Since the requests level are low and likely from the same region we don't have to think about distributing database into multiple regions.

Future improvements

in cases where payment system fails for long time, we should have a free day and let the cars leave with no problem

we should always try a few times before resorting to let the customers leave