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...
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
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