System requirements


Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

  1. allow user to select/recommend available parking lot based on vehicle size, user preference
  2. allow user to exit parking slot
  3. allow payment



Non-Functional:

List non-functional requirements for the system...

  1. Highly available: If system is not available it may create traffic chaos.
  2. Consistency: during network partition if multiple user get assigned same parking lot it will be bad experience
  3. Scalable: During special events or office peak shift time, high demand of service.



Capacity estimation

Estimate the scale of the system you are going to design...

  1. Traffic: 50 requests/sec for entry, 50 requests/sec for exit. Total avg 100req/sec
  2. Bandwidth:
  3. Storage: It parking has 500 physical vehicle space. Each parking lot will map to storage. Each parking slot will take 300Bytes. 500 * 300 bytes.





API design

Define what APIs are expected from the system...


  1. showAvailableSlots(Vehicle)
  2. bookParkingSlot(Vehicle, parkingSlot)
  3. exitParkingSlot(parkingSlot)
  4. payment(parkingSlot)


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

  1. ParkingSlot:
    1. dimension
    2. floor number
    3. id
    4. status
  2. Vehicle
    1. entryTime
    2. vehicleNumber
    3. exitTime
    4. parkingId



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


  1. Client send bookParking request to api gateway. Gateway forwards it to authentication. If authentication successful, gateway forwards it to booking service.
  2. booking service checks availability of parking slot based on given vehicle and user preference. If parking slot available, it books the slot and return the parking slot to client.
  3. When client exit parkingslot, it send parkingExit request to api gateway. Api gateway forwards it to booking service. booking service calculates the charges based on entryTime and exitTime and other fee. It redirects the user to payment gateway.





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

  1. API Gateway: The granularity of APIs provided by microservices is often different than what a client needs. Microservices typically provide fine-grained APIs, which means that clients need to interact with multiple services. Hence, an API gateway can provide a single entry point for all clients with some additional features and better management
  2. Database: index on parkingSlotId and index on status will optimize fast query on available slot. booking and exit of parking using index will boost fast response of booking service.





Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

  1. Relational vs No-SQL database: Since we require strong consistency to avoid duplicate slot booking and also the size of DB won't grow so much so we can tradeoff on horizontal scalability by choosing relational database.
  2. Data sharding: We can partition the data based on parking slot it. Maintain index on parkingSlotId. It will help on fast query response time.





Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.


  1. Data Inconsistency: Same parking slot booked by more than one users.
  2. performing analytics using relational database is bottlenecks.


Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?


  1. Feature to navigate user to its parked vehicle location.
  2. auto payment on exit parking.
  3. Membership plan for regular customers.