System requirements

Functional:

• User can enter the parking lot with an assigned position
• User gets a ticket containing information for the parking such as space assigned, entry time, payment
• User can pay with the ticket at a payment station
• Enforce security by monitoring number plate of each position

Non-Functional:

• Support 500 cars initially for one parking lot
• The system can be later scaled to support multiple parking lots
• Hi availability
• High consistency: we should re-assign a parking lot that already assigned
• Respond in real time
• The system should consider various factors such as space optimization, accessibility

Capacity estimation

• A parking lot has 500 position, so max user is 500
• Assuming average time to stay is 1 hour, then for one day: 24 * 500 = 12K ticket per day
• We can assume one ticket info is 1K byte, if we store ticket data for 10 years, then the total storage size is 1K * 10 * 365 * 12K = 43GB

It can be easily handled by one SQL DB server, we can use one server with replication to ensure availability and avoid single point of failure

API design

1. Publish a ticket
2. Post v1/ticket
3. Body {Vehicle_type, plate, is_ax}
4. Pay a ticket
5. Post v1/payment
6. Body {ticket_id, CardInfo}
7. Exit
8. Post v1/exit
9. Body {ticket_id}
10. Monitor client
11. Post v1/position
12. Body {position_id, plate}

Database design

1. Ticket table
2. ticket_id
3. entry_time
4. leave_time
5. position
6. plate
7. payment
8. isAx
9. level
10. type
11. Parking table
12. position_ID
13. position
14. type
15. isAx
16. level
17. distanceToEntry
18. assignedPlate

High-level design

1. Gate Client
2. Publish a ticket to a user
3. Ticket service
4. Handle the ticket request and generate a ticket to return to gate client
5. Parking DB
6. Store parking table
7. Ticket DB
8. Store ticket table
9. Payment Station
10. User pay ticket
11. API gateway
12. Route API requests to different service machine
13. Payment service
14. Handle payment of a ticket with 3rd party payment platform such as Stripe
15. Monitor client
16. Monitor parking position with cameras and send position, number plate info to monitoring service
17. Monitoring service
18. Check position-plate info matches DB record or not, publish alert message to message queue if not
19. Message queue
20. Receive alert message, we can use Kafka as the message queue
21. Notification service
22. Subscribe to message queue and raise alert notification to security client

Request flows

User park

1. User initiate parking request at GateClient with car info: car type, isAx
2. Gate client sends a ticket request via API gateway to ticket service. The service find an available position, then write a record in ticket table and assign plate in the parking table for the assigned position
3. Gate client publish a ticket to user with assigned position

User payment

1. User can pay the ticket at payment station
2. Payment station sends the request to payment service with ticketId, the service check ticket table for entryTime to calculate the duration and final cost with information such as level, isAx, type
3. Then the service send a payment request to 3rd party platform such as Stripe to finish payment. The service update paid field for ticket entry in ticket table
4. Once the payment succeeded, the ticket will be returned to the user with a paid mark

User leave

1. At gate client, user can use ticket with paid mark to exit
2. The gate client send an exit request to ticket service, then the service update the corresponding parking entry in parking table's assigned plate field to empty and return success to the client
3. Then the gate opens and let user exit

Security monitoring

1. Monitor client sends position-plate mapping data to monitoring service periodically, e.g each 5min.
2. The service can check in parking table, whether the assigned plate matches the current record or not
3. If it does not match, the service publish an alert message to message queue
4. The notification service subscribe to the message queue, when receive an alert message, it sends an notification to security client

Detailed component design

1. Assign a position
2. Based on the car type, isAx, we can assign a position that is currently available and has the lowest distanceToEntry and lowest level as the current ticket, we can sort the parking table by these information
3. When the small car space is full and a new small car is coming, we allow to use larger space such as SUV space. We won't do this for motorcycle in order to use the space efficiently

Trade offs/Tech choices

1. Ticket table
2. The car type, isAx level and position info has already been stored in parking table. One trade off we can consider is that whether it's worth to also store them in ticket table for ticket info. The pro for it is that during payment calculation, we only need to query ticket table to get all needed information for calculation without another query to parking table. The con is that it increases each ticket entry by 10+ byte. As the increased data is small, we think it's a good trade-off

Failure scenarios/bottlenecks

• No more position
• No ticket is created, the gate client should notify the user no more position to park
• Payment failed
• User should be able to retry the payment at payment station

Future improvements

1. Monitoring
2. Periodically checking 5min may introduce false alarm, e.g. if a car temporarily stopped at the position in order to park into another space and the 5 min window just happen to be triggered. To improve the case, we can update the logic in monitor service, only when 2 consecutive data has wrong match, then publish a alert message to the queue