System requirements

Functional:

1. User to login
2. Looking for consistency & availability
3. User can make a reservation / booking a parking slot
4. User can have vehicle types
5. User can select Parking lot
6. space type => ( Regular, Handicap )
7. Payment is integrated with third party - like stripe

Non-Functional:

1. We want to have a high availability -> meaning everytime the users wants the system to be highly available -> with low latency

Capacity estimation

1. Daily active usages of a user wanting to have a space => 2
2. Maximum spaces in Parking Lot => 15000 Spaces
3. 30000 reservations per day
4. 2000 requests / hr -> throughput

API design

Base Url: api/v1

End points:

1. POST -> /reservation -> { user_id, space_id, vehicle_type, is_paid, start_time, entry_id, exit_id }
2. GET -> /availability -> { no_of_available_spaces, spaces_type )
3. POST -> /user -> { name, email, phone_number }
4. GET -> /invoices -> { reservation_id, amount_paid, reference }

Database design

MySQL - Relational Database

1. users
   1. id -> primary key, auto-increment, indexed, Not Nullable
   2. name -> varchar
   3. email -> varchar(255)
2. parking_lots
   1. id -> primary key, auto-increment, indexed, Not Nullable
   2. name -> varchar
   3. postcode -> varchar
   4. address -> varchar
3. entries
   1. id - primary key, auto-increment, indexed, Not Nullable
   2. parking_lot_id: foreign key
   3. entry_reference -> varchar
   4. entry_name -> Entry - 1, 2, 3, etc
4. exits
   1. id - primary key, auto-increment, indexed, Not Nullable
   2. parking_lot_id: foreign key
   3. entry_reference -> varchar
   4. entry_name -> Entry - 1, 2, 3, etc
5. reservations
   1. id - primary key, auto-increment, indexed, Not Nullable
   2. user_id
   3. vehicle_type: enum ( regular, compact, XUV, Truck )
   4. paid: boolean
   5. start_time: Datetime stamp
   6. end_time: Date time Stamp
6. spaces
   1. id - primary key, auto-increment, indexed, Not Nullable
   2. parking_lot_id: foreign key
   3. space_type: enum(( Regular, Handicap )
   4. cost_per_hour: double
7. invoices
   1. id - primary key, auto-increment, indexed, Not Nullable
   2. reservation_id
   3. amount
   4. paid

High-level design

Client App -> Load Balancer -> Booking Service

-> Invoice Service

-> Payment Engine Service

-> Notification Service

-> Redis Cache for Parking & Entries and exists -> can be fetched also from read replica

-> available spaces are pushed into elastic search ->

-> if a space is released or booked, it can be re indexed in real time too

-> Use Scheduler to generate invoices or notification services

-

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

Failure scenarios/bottlenecks

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

Future improvements

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