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.)...
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...
Client sents API request to Booking service server, then this server checks the database for Available parking spots, then user choose a spot and send a post request to reserve it, then the database row is locked and cannot be edited, the booking service then routes clients request to payment service, maybe external payment service through a gateway. the payment service should follow ACID properties and also use idempotency key for not accepting duplicate payments. After the payment was successful the booking service writes to the row where parking spot should be taken for specific time mentioned by Client. Should client choose to move out before the end time, client can and, when client moves out the gate stores timestamp of car out time and immediately the spot linked to the car will be kept available. will the car in time is noted at the gate when it comes in, the gates would be opened only if the payment is successful. check car service here checks the car inbound and outbound time and updates to the database.
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.
Client sents API request to Booking service server, then this server checks the database for Available parking spots, then user choose a spot and send a post request to reserve it, then the database row is locked and cannot be edited, the booking service then routes clients request to payment service, maybe external payment service through a gateway. the payment service should follow ACID properties and also use idempotency key for not accepting duplicate payments. After the payment was successful the booking service writes to the row where parking spot should be taken for specific time mentioned by Client. Should client choose to move out before the end time, client can and, when client moves out the gate stores timestamp of car out time and immediately the spot linked to the car will be kept available. will the car in time is noted at the gate when it comes in, the gates would be opened only if the payment is successful. check car service here checks the car inbound and outbound time and updates to the database. If the reservation is success and updated to database, but still the car doesn't show up, the check car service checks the database for every 1 minute for cars that are reserved but didn't show up, it waits for 15 minutes and the reservation should be cancelled and send the notification to the client about that and send a partial refund back. If the car is checkin and checked out push notification as thank you and also push payment notifications which does it asynchronously.
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 has User table with userid, name, phone number, email.
Payment table for payment information success or failure
check-in-out tabe to enter timestamps of inbound and outbound times.
Reservation table for reserved from and to times.