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
- should be highly reliable & available
- It should be scalable
- the system should be highly consistent
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) check-in POST, for a given vehicle type it will check if a spot is available. if yes, call transaction service & wait for the response. if yes, payment successful, spot reserved & update user table (contact details, ratings [no update to this field]). if payment fails, retry. if no spot available, check 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 -- & we can also store a separate field in user table for (fine/warning issued, & collect fine if late). If we implement fine collection in future for late checkout, we can have a call to transaction service in this step
3) when vehicle crosses gate-in device, POST. update inventory table with check-in, checkout time & vehicle details
4) when vehicle crosses gate-out device, make a POST call to checkout API & free up the corresponding vehicle's row from the inventory table
5) transaction service. This could be an external service, which accepts monetary transaction and returns it's status
6) notification api. We will have a poller which should run every five 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 facing APIs: reserve a spot. updates user table & updates spot in inventory
2) IOT devices which registers check-in & check-out. These directly updates the inventory table
3) poller (a cron job) 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 (sms). the next notification will be 2-5mins before checkout, and one more post checkout time with a fine being added
4) the api server is stateless in our case, ensuring high scalability, which forwards the incoming request to load balancer, which in turn sends the request to the reservation service
5) transaction service
6) Database:
6.1) User table (contact detail, rating, warning/pending_fine issued).
6.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)
7) Load Balancer: it should route requests across multiple instances to save any instance to be overwhelmed. We should also rate limit incoming requests from a single IP
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.
Transaction 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
Cache: If the load increases too much over time, have a cache over inventory table which stores whether a spot is available for a given vehicle type (if not, when is the next spot expected to be available). We will update cache after every checkout & checkin (only update for the given vehicle type not the entire cache db). Structure of Cache: columns (vehicle-type), availibility (yes, ETA)