System requirements

Functional:

* Customer entries

* Customer exits

* Customer pay

Non-Functional:

* The system need to be consistent

* The system need to be correct

Capacity estimation

* 1000 vehicles per day, QPS is approximately 0.01

* 500 parking spaces

API design

GET /v1/park/slots

Get the number of parking slots available

POST /v1/park/entry

{

vehicle_type: int,

time_t: timestamp

}

return customer_id if success

Customer entries to the parking lot

POST /v1/park/exit

{

customer_id: int

}

Customer exits

POST /v1/park/pay

{

customer_id: int,

payment_details: json

}

Database design

I would use a relation database like PostgrasDB. I would create the following tables.

parking

• parking_lot_id: int
• total_num_spaces: int
• occupied_spaces: int

This table store the total number of available slots and slots occupied by customers.

customers

• customer_id: int
• entry_time: timestamp
• exit_time: timestamp
• has_paid: bool
• vehicle_type: int

This table stores the customer information.

High-level design

1. When a customer comes, it requests to enter the parking lot with its plate number.
2. The request is sent to the entry service, which check the `parking` database to see if there is available slots. If yes, it write customer's information into `customer` database and return the generated customer_id, otherwise it return fail to the customer which means the parking lot is full.
3. If step 2 success, customer get its ticket with customer_id, and enter the parking lot.
4. Before exit, customer must pay with its customer_id and payment methods. For security reason, this part should be down with a third party paying service.
5. If payment success, update the status of the customer in `customer` table with `has_paid` field to be true
6. When exiting, the exit service will check if the customer has paid. If yes, it will let the customer go. Otherwise it promote the customer to pay.

Request flows

Similar to high level design.

Detailed component design

Since the QPS and number of customer per day is small. A single server with a replica should be able to handle the services.

Trade offs/Tech choices

No needed for this problem.

Failure scenarios/bottlenecks

Since the services are stateless, and can be easily scale horizontally. There is no single point of failure.

Future improvements

No needed for this problem.