System requirements

Functional:

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

1. Reserve a space for an allotted time, pay through a third party application and get a ticket/receipt for payment
2. Look up available parking spots
3. Cancel an existing reservation

Non-Functional:

List non-functional requirements for the system...

1. System must be highly consistent so no collision occurs and two spaces are not reserved at the same time, can sacrifice some latency for this
2. Should be able to connect with third party applications well; i.e. Stripe for payment, potential Calendar application integration
3. Be regionally available for support for 10 different countries

API design

Define what APIs are expected from the system...

Public Endpoints

• /api/v1/reserve

POST Request - User provides paking_space_id and reservation_id is serializable which gets generated after a third party service (Stripe) validates user has paid through a token.

Request:

{

"reservation_id":"124916",

"parking_space_id": "12",

"parking_lot_id" : "2",

"name" : "Stephen"

}

Response:

{

"receipt_id": "1206",

"expiration_time": "2024-10-01 14:00:00"

}

• /api/v1/cancel/{reservation_id}

DELETE Request - User provides reservation_id so that they may cancel their current parking space reservation

Request:

{

"reservation_id": "124916"

}

Response:

204 HTTP Status code

Internal Endpoints

• /api/v1/calculateFreeSpots

GET Request - Used to calculate how many free spaces we might have available in a parking lot to display on our web app or outside the garage. Calculation can be done through a series of SQL transformations like COUNT on a specified parking lot and doing a query on status of each spot.

Request:

{

"parking_lot_id":"2"

}

Response:

{

"available_spaces": "13"

}

Gate Checking Service API Requests

• /api/v1/vehicleArrived

UPDATE Request - Used to detail when car has arrived to its reserved parking space and update existing record. Service exists to address no show appointments and free up potential spaces.

Request:

{

"reservation_id": "124916",

"time_arrived": "2024-10-01 12:00:00"

}

Response:

204 HTTP Response

• /api/v1/vehicleLeft

UPDATE Request - Used to detail and update existing record on when car left

Request:

{

"reservation_id": "124916",

"time_left": "2024-10-01 13:00:00"

}

Response:

204 HTTP Response

• /api/v1/payment

(Handled by third party - Stripe, Token generated upon completion of payment to proceed with reservation)

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

• Utilize CDN (Pull-based since content is static - AWS CloudFront) due to 100 parking lots in 10 different countries, differences in currency and price. CDN also helps in showing spaces only relevant to client i.e. within the same city
• Use Gate checking service at individual parking lots to determine if a car has shown up or left for its reservation.
• Load balancer for distributed system (AWS Network Load Balancer since high amount of reads), with servers in multiple availability zones, can use AWS EC2 servers set up across multiple regions/Availability zones
• Multiple SQL database replicas to support availability across multiple countries with good support for reads. Synchronous replication across databases to ensure consistency at the cost of slight latency to ensure no collision is happening for the same parking spots.

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

• CDN serves to show most readily available parking lots to client based on location
• Gate checking service sends API Requests to notify when cars have arrived and left for their reservation. If car has not shown up within 15 mins of the start of their reservation then their reservation is automatically cancelled.
• Load Balancer (AWS Network Load Balancer - due to multiple reads and high volume of traffic data) - can utilize Geolocation based load balancing to match clients closer to their parking lots. Could also include some weighted policy to the load balancer for high volume areas (NYC).
• Cache is being used with a LFU eviction policy for high traffic read requests. We delegate to LFU eviction policy because there are certain parking spaces that are used more frequently than others and for the most part will be in traffic majority of the time.

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

• Use relational database (Postgres), not a high amount of data to justify excessive scaling for database through NoSQL
• Lots of relational transformations possible, i.e. joins based on parking_lot_id to find total number of available parking spaces in a particular country/city
• Relational databases are good for avoiding collision too due to ACID properties

Tables:

Parking_Lot_Tbl

Schema

parking_space_id (int: Primary Key - Unique)

parking_lot_id (int)

reservation_id(int)

space_type: (varchar)

address: (varchar)

city: (varchar)

country: (varchar)

time_arrived: (datetime)

time_left: (datetime)

available: (boolean)

Transaction_Tbl

Schema

reservation_id(int: Primary Key - Unique)

receipt_id (int)

name: (varchar)

parking_space_id: (int)

space_type: (varchar)

date: (datetime)