System requirements
Functional:
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
- Parking slots management, lock, unlock, reserve.
- User allocate slot, at gate or on App.
- Parking fee calculation.
Non-Functional:
List non-functional requirements for the system...
- Performance.
- Availability
Capacity estimation
Estimate the scale of the system you are going to design...
- For each level, say we have 200 slots, so the overall storage need is not large.
- But for each car, say we have 10000 cars per day, each record is 10MB, we need 100GB per day, 36TB per year.
API design
Define what APIs are expected from the system...
- getSlot(slotType), get an available slot.
- releaseSlot(), release the taken slot.
- reserveSlot(), to reserve a slot
- query(), for hisotrical query
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...
- SlotDB {slotId: int, location: Location, priceID: int, slotType: SlotType}
- PriceDB {priceID: int, price: Price}
- UserDB {userId: int, userInfo: UserInfo}
- ReserveDB {userId: int, slotId: Int, startTime: TimeStamp, endTime: Timestamp}
- LogDB {userId: int, slotId: int, startTime: TimeStamp, endTime: TimeStamp, cost: int}
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...
- For getSlot API, query the DB, find the nearst slot of the requestType, and send back to user.
- For releaseSlot API, we check the DB for the parking fee, after user pay the fee, update the database.
- For reservation API, we find an available slot from the DB, and return to User
- Notification service will notify user about the reservation, payment.
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...
- For payment, notification, usually we just use third-party compnents, if for the purpose of decoupling, we can use Message queue to decouple the suppler and consumer part.
- For DB, we use Mysql since the data is not that large, we create Index to for better performance.
- For out-of-date data, we dump to cold storage on daily basis.
- For faster query on DB, we add cache to store the latest queried data.
- For the avaialbility, we use master-slave architecture for the DB implementation.
Trade offs/Tech choices
Explain any trade offs you have made and why you made certain tech choices...
- We use MySql because the data size is not so big, and for out-of-date data, we migrate to cold storage, so for hot data, MySql is ok to hold it.
Failure scenarios/bottlenecks
Try to discuss as many failure scenarios/bottlenecks as possible.
- For webServer, we can add multiple replicas, and use loadBalancer to hold it.
- For Payment and notification, we can add more instances incase some instances' failure.
- For database, we use Mysql, but if the data size is too large, and Mysql can not hold it, we can change to NoSql for a better performance.
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
- This is only for a single parking field, if we want to hold multiple fileds, we need ot improve every compoenent for better performance.
- For mapping, we can have mapping service in App to guide users to the slot more easily.