System requirements

Functional:

1. User should be able to make reservation to book the park lot if available
2. User could get the park lot location and available in real time
3. Each park lot has a detail information like space (large or small) for different cars. or if this park is for disabled individuals
4. We should also highlight if this park has charge stations.
5. We should allow user to book a park lot in advance.
6. We should integrate with payment system to pay the parking fee
7. User could cancel their parking if they could not arrive in time.
8. We will keep the parking lot 15 minutes after the reservation time and cancel it automatically.
9. User would get their notification if their reservation is success.

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

Non-Functional:

List non-functional requirements for the system...

1. System should be high availability
2. System should handle the case of concurrent like different user book the same park lot in same time
3. We should consider future growth of users and scalability
4. We should keep our data security
5. We should keep a low latency for book reservation and get the response of availability

1. Let's assume the daily active user is 100000
2. We assume only 80% of them will try to book a park, and all of them will get the park information at least 5 times.
3. So the estimation write traffic would be 100000*0.8=80000 per day = 50 per minutes. and read traffic would be 100000*5 per day = 350 per minute = 6 per second
4. Consider future growth, let's double the traffic, the write traffic would be 100 per minute = 2 per second. the read traffic would be 6*2=12 per second
5. Consider there may be traffic spike in holiday, let's double again , so the peak write traffic in future would be 4 per second and read traffic would be 20 per second
6. Let's go to the storage capacity, assume each reservation record cost 1KB, we take 4 record request per second , so daily record would be 24*4*3600*1KB=345MB, if we keep one replica, it should be 700MB, so yearly storage would be 700*365 = 255GB. we keep 4 year data retention for analysis, we need 1TB storage.

API design

1. book a reservation
   1. POST /reservation/{user_id}/{park_lot_id}?start_time=${start}&end_time=${end}&type={type}
2. cancel a reservation
   1. DELETE /reservation/{reservation_id}/
3. Check available lots
   1. GET /reservation/{park_lot_id}/availability?start_time=${start}&end_time=${end}&type={type}
4. Pay the parking fee
   1. POST /payment/{reservation_id}
5. Get real-time available of parking lot
   1. GET /reservation/{park_lot_id}/start_time=${start}&end_time=${end}&type={type}
6. Get detail information of a paring lot
   1. GET /park/{park_lot_id}
7. Manage user's reservation
   1. GET /user/{user_id}?type=${type}

Database design

1. User
   1. user_id PK
   2. user_name
   3. create_time
2. Vehicle
   1. vehicle_id PK
   2. user_id FK
   3. vehicle_type enum
3. Park_lot
   1. park_lot_id PK
   2. total_capacity
   3. small_size_park_capacity
   4. median_size_park_capacity
   5. large_size_park_capacity
   6. charge_station_park_capacity
   7. longitude
   8. latitude
   9. address
   10. status
4. Reservation
   1. reservation_id PK
   2. user_id
   3. vehicle_id
   4. start_time
   5. end_time
   6. need_charge boolean
   7. reservation_status
   8. pay_status

High-level design

1. App server
   1. user's side app to access our system
   2. server sider administration system to manage the park data
2. API Gateway
   1. route traffic to different service and rate limitation and audit log
3. Reservation service
   1. To handle the request of add update or cancel the reservation
4. Park-lot service
   1. To handle the add update request for park lot
   2. Return the real-time available information of park-lot
   3. To check if park lot have available lot for user
5. Payment Service
   1. implement payment of user
6. Notification Service
   1. push notification to user if his reservation finished
7. Auth service
   1. authenticate user request to keep data security
8. Feedback service
   1. collect user's feedback
9. Loadbalance
   1. keep traffic balance in different server
10. Cache
    1. cache data so give faster user experience
11. DataBase
    1. store our data

Request flows

Reservation

1. user request hit api-gateway and loadbalance, redirect to reservation service.
2. reservation service will call park-lot service to check if available lot in this park-lot.
3. if so, reservation service will create a record and save into db
4. Then it will trigger a async task to notify user that his reservation is done

Payment

1. When user's car arrive the park-lot, parking service will record this action and update the status of reservation
2. when user leave, park-service will calculate the fee based on time and call payment service
3. payment service will start a transaction ask user to pay

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

Database

• The biggest trade off here is using RDBS instead of NoSQL, because:
  • our payment service and book service has high requirement of transaction, eg ACID. this is a big pros of RDBS
  • our data capacity is not extremely huge so RDBS is okay to handle this
• RDBS:
  • pros: ACID transaction guaranteed, strong consistency view of data
  • cons: we need to design our data schema carefully
• NoSQL:
  • pros: data schema is flexible to change. more easy of horizontal flex up
  • cons: eventually consistency instead of strong consistency, NO ACID transaction

Failure scenarios/bottlenecks

Failure scenarios

1. Concurrent reservation request
   1. Scenario that different user make a reservation to same park-lot and there is only one available park.
   2. one user would get the failure return information and he need to retry to make another request
2. Notification service failed
   1. As our notification is an async task to give more faster user experience, but it may failed,

bottlenecks

• In peak time, there may a large amount of user to book reservation , so the database performance would be a bottleneck
  • We could shard the database based on different country or location
  • We introduce a cache so the read traffic would hit cache first and it will return directly if cache hit

Future improvements

• Notification service failed
  • We could have retry mechanism or has a message queue