Detailed Component Design

Database design

data nature
- relationship
  - 1 User: Many parking lot
- schema datatic
choices
- noSQL database
  - we can use document database to store the data
  - document will look like this
    - user_id: id: user's id
    - username: str: user's name
    - parking_lot_reserved: list[object]: list of document of parking lot reserved
  - parking lot document will look like this
    - parking_lot_id: id: parking lot id
    - start_time: timestamp: start time
    - end_time: timestamp: end
- SQL database
  - we can create 3 tables
  - User
    - user_id
    - username
  - Parking lot
    - parking_lot_id
    - parking_lot_location
  - User_Parking
    - user_id
    - parking_id
    - start_time
    - end_time
    - status
- in this case the sql database is more preferred. As the data has consistent structure. And it the document db's structure is a bit awkward here.
In this system we also need to shard databases to support the write transaction (800 rps). The most preferred option is to shard User_Parking Table with parking_id. And we will try to maintain the size each shard to stay the same. For the less popular parking spot it will remain on the same shard. While the more popular shard can have multiple shard.
We also needed to index the User_Parking Table by parking_id, start_time for quick search as parking_id, start_time is frequently used by service such Reservation Service, Check In service and Check Out Service
we also delete every data that lived longer than 30 days to save space
Strict consistency needed to be enforced here. The write will not return Success until every replica have synced the data with the write node

No Show Monitoring Service

To prevent the user to irresponsibly book the parking spot if the parking spot is not checked in within 15 minute. The reservation will be canceled.
We can do this by periodically (every 30 minute about xx:15, xx:45) query if the staus = "Reserved" and start_time = curr_time-15
We removed those reservation from the db

Spot Allocation — Scenario Checks

We put queue after the reservation service.
In case there is demand to reserve the same spot at the same time, based on order in queue, queue will reroute the older request to database.
and the later request will encounter the database that inform it that the spot is reserved and return 409 conflict

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10