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
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) Reservation service api, 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 inventory with check-in, checkout time & vehicle details, update user table (contact details, ratings [no update to this field]) & spot reserved. 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) Reservation service, 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). If we implement fine collection in future for late checkout, we can have a call to transaction service in this step
3) transaction service. This could be an external service, which accepts monetary transaction and returns it's status
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
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
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
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
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
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)