Loading...
List functional requirements for the system (Ask interviewer if stuck)...
Register a new park lot entry and exit
Control of available places
Customer charge
List non-functional requirements for the system...
The data needs to be consistent, to avoid two users trying to park in the same place
The system needs to have good UX experience
The system needs to be reliable
Estimate the scale of the system you are going to design...
Define what APIs are expected from the system...
POST api/v1/entry
request: {}
response: { tickerCode: string }
POST api/v1/exit
request: {}
response: { isTicketPaid: boolean }
POST api/v1/ticker/{id}/payment
request: {
tockerCode: string
}
response: {}
GET api/v1/ticker/{id}/details
response: {
duration: DateTime
amount: BigDecimal
}
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 believe that if the user lost the ticker it should expire in some hours
Tickers
id: uuid
createdAt: datetime
Period
tickerId: uuid
status: [IN-PROGRESS, PAID, EXPIRED]
startedAt: datetime
endedAt: datetime
expiredAt: datetime
Lots
id: uuid
tickerId: uuid
status: [Available, Unavailable]
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...
entry machine: that will generate a new entry
exit machine: that will generate a new exit
charge machine: that will be used for the user to pay the ticker
cron job: that will check for expired tickers.
webserver: that will handle the request and acknowledge a entry, exit or a payment
Relational database: will be in charge of the ticker data
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...
Entry Machine: The user press a button, this button will generate a request to the web server that will first, validate available places, second create a new ticker with a jwt-token that will be encoded and sent back to the user, third assign a pre-created lot for a ticker, this both information will be printed as qrcode
Charge Machine: The user scan the token on the machine, It will trigger a request that will first validate the token, second get the details data about the amount to pay end duration time, so the user can start a payment in the charge machine, once paid it gonna trigger a request to the webserver, that will register a endAt and update the Period status
Exit Machine: For the exit machine, the user should scan the ticker, the token and ticker will be validate using the periods created, if it is paid and everything is ok the user can leave the place and the lot register will be released
Cronjob: The cronjob will be used expire the ticker after x minutes of the payment to avoid the user of pay and not leave the place, also we should have a max period limit in case of the ticker be lost to release the parking lot blocked.
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...
Explain any trade offs you have made and why you made certain tech choices...
I chose a relation database because of the ACID properties to guarantee that are available lots before a user park
I chose a rest API because of the simplicity of the request and clients that will be using that
Try to discuss as many failure scenarios/bottlenecks as possible.
We could have network failure between the client and servers it will make the system temporally unavailable, but It will avoid inconsistencies in the system, due is a park lot we need to guarantee that he same person that generate the ticket are using that to leave the place also we need to guarantee available lots
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?