Requirements
Functional Requirements:
- Allow reservation of a parking spot.
- Process payment for the reservation.
- Enable parking of a car in the reserved spot.
- Support early departure before reservation time expires.
- Gate check-in/out.
- Handle no show.
Non-Functional Requirements:
- List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...
- Whenever a car enters, if space is available, then the wait time should be low
- should have provision to support a new vehicle type in future
- given a car, should find it's spot instantly
API Design
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
1) checkin POST, checks inventory if we have space available for a given vehicle type. If yes, allow checkin, update details in inventory table (check-in, check-out) & update user table (contact details, rating [no update to this field]). If no, in inventory table, for a given vehicle type, sort by check-out times & let the user know that it is expected to have a free space in xyz minutes
2) checkout POST. If current_time is less than checkout, improve user rating in the user table (rating ++), free up a row in inventory table. if current_timie > checkout, rating -- & delete a row in inventory table, we can also store a separate field in user table for (fine/warning issued, & collect fine if late)
3) internal payment service api, to be triggered during checkout
4) notification api. We will have a poller which should run every 5 minutes, and check if there's any vehicle that is nearing checkout time & send a notification to the user.
High-Level Design
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
1) user arrives for check-in -> check inventory table -> collect user info in user table -> redirect to payment gateway & wait for confirmation -> update inventory table with check-out details & vehicle is parked
2) users arrives to recieve their vehicle:
2.1) if current time <= checkout-time: remove the vehicle inventory from DB, update user rating ++
2.2) if current time > checkout-time: remove the vehicle inventory from DB, update user rating --, add fine (redirect to payment gateway)
3) poller which polls the inventory DB every 5 minutes. Checks if there is any vehicle to be checked out in the next 15 minutes, send a user notification. the next notification will be 2-5mins before checkout, and one more post checkout time with a fine being added
Detailed Component Design
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
Database:
1) User table (contact detail, rating, warning/pending_fine issued).
2) inventory (vehicle type, parking spot, check-in time, check-out time)
Relational SQL DB is sufficient, but we can opt for NoSQL DB if we feel a need to add more fields in the future (is the vehicle EV, does it need charging, driving license details, etc)
Poller: a cron job
Notification Service: sms service
Payment Gateway: can use an external service
Parking spot finder service: for short duration parkings, we can give a spot nearer to entrance gate. For longer durations, we can give farther away spots