System requirements
Functional:
User can create an account
User can reverse a parking slot
User can update the reservation
User can pay parking so that it creates a new reservation in the system
System should give an appropriate parking slot to the user considering the car size
System should allow long term and short term parking
System should manage no show users and late users
System should send notification to user before the reservation is opened
Administrator should be able to add new parkings
Non-Functional:
List non-functional requirements for the system...
Should be highly available and secure for payments
System should have good performance and be able to scale to handle pike of users
Capacity estimation
Estimate the scale of the system you are going to design...
10 parkings of 200 places to manage
1000 users a day doing 10 request each
so 10000 request a day
API design
Define what APIs are expected from the system...
POST user(username, password): UserId
DELETE user(UserID)
POST reservation(parkingId, carSize): ReservationId
PUT reservation(parkingId, carSize)
POST payment(parkingId, userId, approved)
POST reservation(userId, fromTimestamp, toTimestamp, carSize, assignedPlace): reservationId
UPDATE reservation(userId, fromTimestamp, toTimestamp, carSize, assignedPlace): reservationId
GET reservation(reservationId): reservationstatus
POST parking(smallPlaces, mediumPlaces, largePlaces, extraLargePlaces): ParkingId
UPDATE parking(ParkingId, smallPlaces, mediumPlaces, largePlaces, extraLargePlaces)
Database design
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
I will use a SQL database as schema is relationnal
table parking
smallPlacesTotal: number
mediumPlacesTotal: number
largePlacesTotal: number
extraLargePlacesTotal: number
smallPlacesAvailable: number
mediumPlacesAvailable: number
largePlacesAvailable: number
extraLargePlacesAvailable:number
isOpened:boolean
localizartion:Coordinates
parkingSpot:
parkingId:string - foreign key on parking
spotId:string
spotSize: Enum
isAvailable:boolean
table users
userId: string
isAdministrator: boolean
password:string
table reservation
reservationId: string
userId:string - foreign key on user
parkingId:string - foreign key on parking
parkingSpotId:string - foreign key on parkingSpot
fromTimestamp: number
toTimestamp: number
table payment
payementId:string
reservationId:string - parkingId:string - foreign key on reservation
userId:string
isAccepted:boolean
isRefunded:boolean
table audit_log
logid:string
reservationId: string - foreign key on reservation
errorMessage: string
High-level design
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
Request flows
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
User will select a parking and reserve a spot then pay using the in place system.
After payement is done a decicated job will take care of assigning the right place to the user
The load balancers are used here to prevent database crashes during pike of users
If a payement fail the error is going in a dedicated dead end queue to be stored in a dedicated noSQL DB
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...
When a reservation is done a dedicated assignementService will be called to affect a dedicated spot to the user. This spot will be at least of the size of the car.
The notification service will be used to signal to the user that the reservation is closed
We will also have the payement service that will need to put lock on the database so that we avoid reservation of the same parking spot;
Trade offs/Tech choices
Explain any trade offs you have made and why you made certain tech choices...
Using a SQL database that is more difficult to scale is linked to the fact that the amount of user and request is of medium size
We used micro service because some of them may rely of different databases
Failure scenarios/bottlenecks
Try to discuss as many failure scenarios/bottlenecks as possible.
Pike of reservation can have impact on database, that's why we provided load balancing and database replication
We can think about managing the late user using a dedicated service
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
We can think about managing the late user using a dedicated service
Add a monitoring board to check reservation issues